Repository navigation
charon: fail the build if a TLS stack is compiled in (CVE-2026-111943) - #1132
Conversation
charon's Cargo.lock pins webpki-roots 1.0.9 (trusts emSign ECC Root CA - G3) and rustls-webpki 0.103.4, and the vendor tarball carries both, so the trust-store scan flags charon. Neither is compiled: reqwest / crates_io_api sit behind the optional `popular-crates-test` feature, and the built charon / charon-driver carry no webpki, rustls or reqwest strings and no denylisted certificate or SPKI. Make that verdict durable: after the build, require a libserde rlib in target/release/deps (positive control) and fail if any rustls, rustls-webpki, webpki-roots, webpki-root-certs or reqwest rlib is there. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review.
 |
| Layer / File(s) | Summary |
|---|---|
Default-build artifact validation packages/charon/build.sh |
After the default-feature build, the script searches Cargo-reported build and target directories. It fails if it finds no serde .rlib or finds an .rlib for a listed TLS-related crate. |
Priority:
Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Bug fix
Possibly related issues
gominimal/pkgmgr-rs#1022— Tracks the CVE-2026-111943 response and lists Rust tools with bundled roots as affected work. This PR adds a build-time check for a related TLS stack in charon.
Possibly related PRs
- gominimal/pkgs#817 — Addresses the same certificate compromise with package-level certificate changes.
- gominimal/pkgs#1114 — Addresses the same trust issue by switching consumers to Chromium.
Suggested reviewers: norrietaylor
Merge Risk: 
3f62d
-
No concrete merge-blocking issue was established. The charon build should still be run to confirm the guard in its package environment.
Pre-merge checks: 
-
Check name Status Explanation Description Check Check skipped - CodeRabbit’s high-level summary is enabled. Title check The title clearly and concisely describes the main change: adding a build failure guard when a TLS stack is compiled into charon. It also identifies the relevant CVE. Docstring Coverage No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Documentation-only edits and deletions within survi… Linked Issues check Check skipped because no linked issues were found for this pull request. Out of Scope Changes check Check skipped because no linked issues were found for this pull request. Full details: Docstring Coverage
-
Explanation
No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 0 functions across 1 files.
-
Finishing Touches
-
📝 Generate docstrings
-
- Commit to this branch
- Create a new PR
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
…d in target/release/deps) The first build of this guard failed its own positive control on both arches: 'no libserde rlib in target/release/deps' although the build finished and the binaries are in target/release (newer cargo keeps intermediate artifacts in a separate build directory). Search cargo metadata's build_directory and target_directory recursively instead; serde stays the positive control. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Confirmed in charon's Cargo.toml at 7980165 that reqwest and crates_io_api are optional and only enabled by popular-crates-test, while defaults are rustc and minirust, so the TLS stack is not compiled into this build. The guard has a serde positive control and runs under set -eu without pipefail, so the grep -q pipelines are safe. The charon build is green on the head with the guard silent.
Part of the CVE-2026-111943 response (gominimal/pkgmgr-rs#1022, the eMudhra intermediate key compromise).
The first fleet
pkgmgr truststoresrun flagged charon: it vendorswebpki-roots 1.0.9, which still trusts emSign ECC Root CA - G3. Checking where that crate actually goes:Cargo.toml(7980165),reqwestandcrates_io_apiare optional and enabled only by thepopular-crates-testfeature, a test that downloads popular crates. The only route to rustls / rustls-webpki / webpki-roots runs through them.build.shbuilds--bin charon --bin charon-driverwith default features (rustc,minirust).cache.minimal.dev, artifact1973bf26…) has nowebpki/rustls/reqweststrings, and none of the 53packages/ca-certificates/distrust.txtcert or SPKI hashes. The same scanner finds emSign G3 and AAA in a pre-fix bundle (positive control).So a lock bump would only change the vendor tarball, with no effect on the binaries. This PR doesn't do that. It adds a build-time guard that keeps the verdict true. After the cargo build step,
build.shnow:target/release/deps/libserde-*.rlibto exist (positive control, so the check can't pass by looking in the wrong place);rustls,rustls_webpki,webpki_roots,webpki_root_certsorreqwestrlib was compiled. The error says to lock rustls-webpki >= 0.103.16 / webpki-roots >= 1.0.10 first.If a future charon bump turns the TLS stack on by default, the build fails instead of quietly shipping the pre-fix roots.
Verification: not built locally. This PR's build is the test: the charon build must pass, with the guard silent. Changing
build.shchanges charon's spec hash, so charon and its dependents (aeneas) rebuild.Follow-up for the scanner (pkgmgr-rs): an uncompiled vendored crate source is the same no-action class as rust's vendored webpki-roots 0.26.3. It should be classified, not reported as a hit.
🤖 Generated with Claude Code
Summary by CodeRabbit