ci(supply-chain): wire cargo audit + cargo deny into a blocking CI gate (SUPPLY-01)#326
Merged
Merged
Conversation
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
Warning Review limit reached
Next review available in: 37 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (4)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
deny.toml existed in the tree but was never invoked by any workflow -- its own header comment said so (SUPPLY-01 in docs/PRODUCTION-CONTRACT.md). Adds .github/workflows/supply-chain.yml with two ubuntu-latest jobs: `audit` (cargo audit, hard-fails on RUSTSEC Vulnerability-class advisories only -- unmaintained/unsound/yanked stay visible-but-non-blocking, cargo audit's own default) and `deny` (cargo deny check advisories licenses bans sources). Triggers: PRs touching Cargo.toml/Cargo.lock/deny.toml/ .cargo/audit.toml, push to main, and a weekly cron (advisories publish independent of code changes). Runs on the hosted runner, not the self-hosted moon-dev box -- this only inspects dependency metadata, no build needed. Fixed three real advisories in the lockfile to reach green: memmap2 0.9.10->0.9.11 (RUSTSEC-2026-0186, unsound pointer-offset validation), crossbeam-epoch 0.9.18->0.9.20 (RUSTSEC-2026-0204, invalid pointer deref in Display), spin 0.9.8->0.9.9 (yanked); bumped rust-embed 8.11.0->8.12.0 (console feature) which drops the unmaintained core2/proc-macro-error2 transitives in favor of no_std_io2/proc-macro-error3. All via `cargo update -p <crate>` -- no Cargo.toml range changes needed, no functional code touched. Verified default, tokio+jemalloc, and console feature builds still compile clean after the bumps. Three unmaintained transitive advisories with no available safe upgrade today (fxhash via monoio 0.2.4, paste via tikv-jemalloc-ctl 0.6.1, rustls-pemfile pending a rustls-pki-types::PemObject migration) are explicitly ignore-listed with reasons in deny.toml and the new .cargo/audit.toml, rather than left to pass silently or leaving the gate permanently red. cargo-deny's advisory matcher additionally misses RUSTSEC-2026-0097 (rand 0.9.2 unsound, via metrics-util -- a narrow custom-logger reentrancy issue moon's tracing-subscriber setup can't trigger) that cargo-audit does catch; ignore-listed in .cargo/audit.toml with the same reasoning for when cargo-deny's matcher catches up. Local validation (cargo-audit 0.22.2, cargo-deny 0.19.6, pinned in the workflow via taiki-e/install-action): both `cargo audit` and `cargo deny check advisories licenses bans sources` exit 0 against the current Cargo.lock. task: #63 (SUPPLY-01) author: Tin Dang
TinDang97
force-pushed
the
worktree-agent-af40bfaa580e57616
branch
from
July 14, 2026 03:19
a955596 to
52ee1f1
Compare
TinDang97
added a commit
that referenced
this pull request
Jul 15, 2026
…es (task #66) rustls-pemfile 2.2.0 is unmaintained (RUSTSEC-2025-0134) with no safe drop-in upgrade in the 2.x line. It was ignore-listed in deny.toml/.cargo/audit.toml when the supply-chain CI gate was wired up (#326) specifically because the real fix required touching src/tls.rs, out of scope for that CI-wiring PR. This closes that follow-up. build_tls_config (src/tls.rs) now parses PEM directly via rustls-pki-types' PemObject trait, already present transitively through rustls's own pki_types re-export: CertificateDer::pem_reader_iter for cert chains (server cert + optional CA chain for mTLS) and PrivateKeyDer::from_pem_reader for the private key. rustls-pki-types is promoted to a direct optional dependency (features = ["std"], needed for the reader-based PemObject methods) gated behind the same runtime-tokio/runtime-monoio feature flags rustls-pemfile used. No behavior change: same fail-loud io::Error wrapping per stage (TLS cert file/parse, TLS key file/parse, CA cert parse), same SIGHUP hot-reload path (src/tls.rs spawn_sighup_reload_thread), same cipher-suite allowlist and mTLS client-verifier logic — untouched. Test coverage gap found during migration: the existing suite only exercised missing-file paths (NotFound), never a genuine DER/PEM decode failure — the exact seam this migration touches. Added two tests exercising well-formed- PEM-markers-but-corrupt-body input directly against the new parser: test_build_tls_config_garbage_cert_parse_error and test_build_tls_config_garbage_key_parse_error, both asserting the expected "TLS cert parse" / "TLS key parse" error context survives the migration. All 11 tls:: tests pass (including the two openssl-backed real-cert reload tests, unchanged). rustls-pemfile is fully removed from Cargo.toml/Cargo.lock. The RUSTSEC-2025-0134 ignore entries are removed from deny.toml and .cargo/audit.toml; `cargo deny check advisories licenses bans sources` (0.19.6) and `cargo audit` (0.22.2) both pass clean against the resulting lockfile with no ignore needed for this advisory. Also updated .add/dependencies.allowlist and .github/dependabot.yml's crypto-tls group to reflect the dependency swap. Verified: cargo fmt --check; cargo clippy -- -D warnings (default features); cargo clippy --no-default-features --features runtime-tokio,jemalloc -- -D warnings; cargo test --lib tls:: (11/11 passed, both feature sets); cargo deny check advisories licenses bans sources; cargo audit. task: #66 author: Tin Dang <tindang.ht97@gmail.com>
TinDang97
added a commit
that referenced
this pull request
Jul 15, 2026
…es (task #66) rustls-pemfile 2.2.0 is unmaintained (RUSTSEC-2025-0134) with no safe drop-in upgrade in the 2.x line. It was ignore-listed in deny.toml/.cargo/audit.toml when the supply-chain CI gate was wired up (#326) specifically because the real fix required touching src/tls.rs, out of scope for that CI-wiring PR. This closes that follow-up. build_tls_config (src/tls.rs) now parses PEM directly via rustls-pki-types' PemObject trait, already present transitively through rustls's own pki_types re-export: CertificateDer::pem_reader_iter for cert chains (server cert + optional CA chain for mTLS) and PrivateKeyDer::from_pem_reader for the private key. rustls-pki-types is promoted to a direct optional dependency (features = ["std"], needed for the reader-based PemObject methods) gated behind the same runtime-tokio/runtime-monoio feature flags rustls-pemfile used. No behavior change: same fail-loud io::Error wrapping per stage (TLS cert file/parse, TLS key file/parse, CA cert parse), same SIGHUP hot-reload path (src/tls.rs spawn_sighup_reload_thread), same cipher-suite allowlist and mTLS client-verifier logic — untouched. Test coverage gap found during migration: the existing suite only exercised missing-file paths (NotFound), never a genuine DER/PEM decode failure — the exact seam this migration touches. Added two tests exercising well-formed- PEM-markers-but-corrupt-body input directly against the new parser: test_build_tls_config_garbage_cert_parse_error and test_build_tls_config_garbage_key_parse_error, both asserting the expected "TLS cert parse" / "TLS key parse" error context survives the migration. All 11 tls:: tests pass (including the two openssl-backed real-cert reload tests, unchanged). rustls-pemfile is fully removed from Cargo.toml/Cargo.lock. The RUSTSEC-2025-0134 ignore entries are removed from deny.toml and .cargo/audit.toml; `cargo deny check advisories licenses bans sources` (0.19.6) and `cargo audit` (0.22.2) both pass clean against the resulting lockfile with no ignore needed for this advisory. Also updated .add/dependencies.allowlist and .github/dependabot.yml's crypto-tls group to reflect the dependency swap. Verified: cargo fmt --check; cargo clippy -- -D warnings (default features); cargo clippy --no-default-features --features runtime-tokio,jemalloc -- -D warnings; cargo test --lib tls:: (11/11 passed, both feature sets); cargo deny check advisories licenses bans sources; cargo audit. task: #66 author: Tin Dang <tindang.ht97@gmail.com>
pilotspacex-byte
added a commit
that referenced
this pull request
Jul 15, 2026
…es (task #66) (#338) rustls-pemfile 2.2.0 is unmaintained (RUSTSEC-2025-0134) with no safe drop-in upgrade in the 2.x line. It was ignore-listed in deny.toml/.cargo/audit.toml when the supply-chain CI gate was wired up (#326) specifically because the real fix required touching src/tls.rs, out of scope for that CI-wiring PR. This closes that follow-up. build_tls_config (src/tls.rs) now parses PEM directly via rustls-pki-types' PemObject trait, already present transitively through rustls's own pki_types re-export: CertificateDer::pem_reader_iter for cert chains (server cert + optional CA chain for mTLS) and PrivateKeyDer::from_pem_reader for the private key. rustls-pki-types is promoted to a direct optional dependency (features = ["std"], needed for the reader-based PemObject methods) gated behind the same runtime-tokio/runtime-monoio feature flags rustls-pemfile used. No behavior change: same fail-loud io::Error wrapping per stage (TLS cert file/parse, TLS key file/parse, CA cert parse), same SIGHUP hot-reload path (src/tls.rs spawn_sighup_reload_thread), same cipher-suite allowlist and mTLS client-verifier logic — untouched. Test coverage gap found during migration: the existing suite only exercised missing-file paths (NotFound), never a genuine DER/PEM decode failure — the exact seam this migration touches. Added two tests exercising well-formed- PEM-markers-but-corrupt-body input directly against the new parser: test_build_tls_config_garbage_cert_parse_error and test_build_tls_config_garbage_key_parse_error, both asserting the expected "TLS cert parse" / "TLS key parse" error context survives the migration. All 11 tls:: tests pass (including the two openssl-backed real-cert reload tests, unchanged). rustls-pemfile is fully removed from Cargo.toml/Cargo.lock. The RUSTSEC-2025-0134 ignore entries are removed from deny.toml and .cargo/audit.toml; `cargo deny check advisories licenses bans sources` (0.19.6) and `cargo audit` (0.22.2) both pass clean against the resulting lockfile with no ignore needed for this advisory. Also updated .add/dependencies.allowlist and .github/dependabot.yml's crypto-tls group to reflect the dependency swap. Verified: cargo fmt --check; cargo clippy -- -D warnings (default features); cargo clippy --no-default-features --features runtime-tokio,jemalloc -- -D warnings; cargo test --lib tls:: (11/11 passed, both feature sets); cargo deny check advisories licenses bans sources; cargo audit. task: #66 author: Tin Dang <tindang.ht97@gmail.com> Co-authored-by: Tin Dang <tindang.ht97@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes PRODUCTION-CONTRACT SUPPLY-01 (task #63):
deny.tomlexisted but was wired into no CI job (its own header admitted it)..github/workflows/supply-chain.yml—audit+denyjobs on ubuntu-latest (not the self-hosted runner; lockfile inspection needs no build). Triggers: PRs touching manifests, push to main, weekly cron (advisories publish continuously), manual dispatch. Tools pinned: cargo-audit@0.22.2, cargo-deny@0.19.6 via pinned taiki-e/install-action.cargo update -ponly — no Cargo.toml range changes.rustls-pki-types::PemObjectis a src/tls change — tracked follow-up), rand-via-metrics-util (unreachable trigger path).Verification
cargo auditexit 0 andcargo deny check advisories licenses bans sourcesall four ok, locally against the updated lockfile.runtime-tokio,jemalloc, and console-feature builds all compile with the bumped lockfile.