Research platform-native TLS trust configuration
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 32/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- rust
- Domain
- cli, documentation, security
Research direction
Review src/http.rs and Cargo.toml to confirm the current bundled-root setup, then read related issues #448, #438, and #445. Compare the listed trust strategies across the supported targets and specified certificate cases. Done means a documented recommendation, rationale, actionable failure behavior, and implementation and test follow-ups, with runtime documentation updated.
Written by the indexing model from the issue text.
Description
Context
The HTTP host currently builds its TLS connector with with_webpki_roots() in src/http.rs, while Cargo.toml enables the webpki-tokio feature. This embeds the Mozilla root set in every basic-cli application and does not use trust configured by the operating system.
Bundled roots make static applications self-contained and allow public HTTPS to work in minimal environments without a system CA bundle. However, a general-purpose CLI may need to honor:
- enterprise TLS interception and private certificate authorities;
- locally trusted development certificates;
- administrator trust and distrust policy;
- operating-system certificate updates;
- standard CA bundle overrides such as
SSL_CERT_FILEandSSL_CERT_DIR.
Research questions
Investigate and document the tradeoffs between:
- a platform verifier;
- loading native roots into rustls;
- retaining only bundled WebPKI roots;
- combining or falling back between native and bundled roots;
- exposing an application-level custom CA configuration.
The investigation should cover:
- x64 and arm64 macOS, x64 Windows, and x64 and arm64 Linux musl;
- static linking, cross-compilation, binary size, and startup/runtime cost;
- minimal containers or hosts with no usable native certificate store;
- whether fallback to bundled roots could bypass an intentional OS distrust decision;
- actionable errors when roots cannot be loaded or a certificate is rejected;
- private CA, public CA, missing-store, and invalid-store test cases.
Desired outcome
Record a recommended trust policy for basic-cli and the rationale behind it. If a change is recommended, define implementation and test follow-ups that provide predictable behavior on every supported target without requiring users to disable certificate verification.
Keep the public runtime documentation updated with the chosen behavior.
Related work
- #448 documents the current bundled-root behavior.
- #438 tracks stable HTTP transport error classification, including TLS failures.
- #445 tracks dependency advisories and rebuild expectations for statically linked applications.
- Dominant language
- Rust
- Stars
- 123
- Forks
- 46
- Avg merge
- 7h 43m
- Merged PRs (30d)
- 16
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from roc-lang/basic-cli
-
Add `Path.parent`Open
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
roc-lang/basic-cli#537 · 1 reaction ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 55/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
roc-lang/basic-cli#482 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 45/100
roc-lang/basic-cli#455 · 1 comment ·
Maintainers usually reply within 1 day
All issues in roc-lang/basic-cli
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
DioxusLabs/blitz#1371 ·
Maintainers usually reply within 1 day
-
follow-up
Difficulty 2/5 Half a day Newbie friendliness 62/100
carrick-sh/carrick#1494 ·
Maintainers usually reply within 1 day
-
test(hydro_std): track_membership join and leave are untestedPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
hydro-project/hydro#3289 ·
Maintainers usually reply within 1 day
-
diagram-bug good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
enhapu-afk/omaspec#4 ·