Repository navigation
chore(deps): pin aws-lc-rs <1.18 to retain AWS-LC-FIPS 3.x backend - #1390
Conversation
aws-lc-rs <1.18 to retain AWS-LC-FIPS 3.x backend
2a55da7 to
acf742e
Compare
❌ ErrorsYour PR has failed checks. Please review the issues below and take necessary action before merging. 🚦 1 Pipeline job failed
Useful? React with 👍 / 👎 This comment will be updated automatically if new data arrives.🔗 Commit SHA: 6b05187 | Docs | View more details | Give us feedback! |
acf742e to
77bfeb0
Compare
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
@DataDog review |
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The focused dependency constraint and lockfile updates are consistent with the stated FIPS requirements and repository conventions.
Review effort: Balanced
Findings: None
What changed in this PR
Pins the FIPS crypto backend below AWS-LC-FIPS 4.x while allowing compatible Rustls updates.
Changes:
- Adds an optional
aws-lc-rs <1.18dependency for FIPS builds. - Updates compatible crypto dependencies in the lockfile.
| File | Description |
|---|---|
bottlecap/Cargo.toml |
Adds and activates the backend constraint. |
bottlecap/Cargo.lock |
Records compatible Rustls and AWS-LC versions. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
There was a problem hiding this comment.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 77bfeb03e4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
The rustls <0.23.45 cap did not reliably constrain the transitive crypto backend: rustls 0.23.37 still permits aws-lc-rs 1.18, which switches to AWS-LC-FIPS 4.x, pending FIPS 140-3 certification. Pin the backend directly (>=1, <1.18), activated by the fips feature, mirroring DataDog/saluki#2348 and DataDog/serverless-components#173. Resolves to rustls 0.23.43, aws-lc-rs 1.17.4, aws-lc-fips-sys 0.13.17. The RUSTSEC-2026-0285 waiver is kept: the fix ships in rustls 0.23.45, which stays out of range.
3318913 to
6b05187
Compare
…he cargo-audit waiver (#1414) ## Problem The "Bottlecap (Rust) / Lockfile Scan" check fails on every branch, for example #1412 and an automated dd-trace-go upgrade branch. Trivy finds advisory GHSA-2mjx-qc3c-rqvc in `rustls` 0.23.43 and exits 1. `main` will fail the same way on its next run. ## Why this PR ignores the advisory The fix is in `rustls` 0.23.45, and we cannot use that version yet: - `rustls` 0.23.45 requires `aws-lc-rs` 1.18 or later. `aws-lc-rs` 1.18 uses AWS-LC-FIPS 4.x, which has no FIPS 140-3 certification yet. Our FIPS builds must use a certified crypto module. So the team reverted the bump to 0.23.45 in #1389, and #1390 pinned `aws-lc-rs` below 1.18. - The non-FIPS builds do not use `aws-lc-rs`, but both builds use the same `Cargo.lock`, so they get the same `rustls` version. - `datadog-fips` from `serverless-components` also requires `rustls` below 0.23.45. In a copy of `main` without our own cap, `cargo update -p rustls --precise 0.23.45` fails on that requirement. #1389 accepted this risk for `cargo-audit`, where the advisory has its RustSec ID, RUSTSEC-2026-0285. The GitHub advisory links to that RustSec page. The advisory says that the handshake transcript stays authenticated, so an attacker cannot change or complete a handshake. The effect is that a peer can send in plaintext some handshake messages that must be encrypted. ## Change Trivy uses its own ignore list, `.trivyignore.yaml`, and that list did not have the advisory. This PR adds GHSA-2mjx-qc3c-rqvc to it, with the same reason. It also adds a line to `bottlecap/.cargo/audit.toml` that names the Trivy entry. Then the person who removes one ignore after the certification also removes the other. `.github/workflows/vulnerability-scan.yml` reads the same file for its daily `Cargo.lock` scan, so that scan also skips the advisory. The daily image scans in that workflow do not read the file, and this PR does not change them. ## Testing ### Steps 1. Copy `bottlecap/Cargo.lock`, `bottlecap/Cargo.toml` and `.trivyignore.yaml` into an empty directory. 2. Run Trivy with the options of the CI step: `trivy fs --scanners vuln --ignorefile .trivyignore.yaml --ignore-unfixed --exit-code 1 --format table bottlecap`. 3. Do steps 1 and 2 for `main` and for this branch. ### Result | Check | Before (`main`, `469decc8`) | After (this branch) | | --- | --- | --- | | Trivy findings | 1, GHSA-2mjx-qc3c-rqvc in `rustls` 0.23.43 | 0 | | Trivy exit code | 1 | 0 | I used the local Trivy installation, not the version and database that CI uses. The CI run on this PR is the real check. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Overview
Pins the FIPS crypto backend directly: adds
aws-lc-rs = { version = ">=1, <1.18" }as an optional dependency activated by thefipsfeature, and removes therustls <0.23.45cap introduced by #1389.Capping
rustlsdid not reliably constrain the transitive crypto backend:rustls0.23.37 still permitsaws-lc-rs1.18, which switches to AWS-LC-FIPS 4.x. AWS-LC-FIPS 4.x has not completed FIPS 140-3 certification; only the 3.x module is NIST CMVP validated. The backend itself is therefore pinned as a direct dependency even though the crate does not callaws-lc-rsAPIs directly, following the approach in DataDog/saluki#2348 and DataDog/serverless-components#173. The pin participates in resolution for both the default and FIPS builds, so a futurecargo updatecan no longer silently re-selectaws-lc-rs1.18.RUSTSEC-2026-0285 is only fixed in
rustls>= 0.23.45, which stays out of range, so the existing waiver inbottlecap/.cargo/audit.toml(and the matchingignoreinrs_ci.yml) is intentionally preserved. This change does not fix that advisory.Removal criteria: lift the
aws-lc-rs <1.18bound and remove theRUSTSEC-2026-0285waiver (frombottlecap/.cargo/audit.tomlandrs_ci.yml, then re-bumprustls) once AWS-LC-FIPS 4.x certification is verified. Once DataDog/serverless-components#173 merges, this local pin can instead be dropped by bumping theserverless-componentsgit rev (currently3ab01258, kept aligned across thedatadog-fips,dogstatsd,datadog-agent-config, anddatadog-agent-trace-samplerdependencies).Testing
cargo metadata --locked(plain and--all-features) succeeds inbottlecap/without modifying the lockfile.cargo tree --locked -i aws-lc-rsresolves to a singleaws-lc-rs 1.17.4for both the default and FIPS builds; the FIPS build activates itsfipsfeature, resolving toaws-lc-fips-sys 0.13.17../scripts/verify_tls_root_features.shpasses: default build keeps webpki roots, FIPS build keeps native roots.cargo clippy --workspace --all-targetspasses for both--features defaultand--no-default-features --features fipswithRUSTFLAGS=-D warnings.cargo nextest run --workspace --locked: 690 passed, 0 failed.cargo fmt --all -- --checkpasses.dd-rust-license-tool checkpasses with no changes toLICENSE-3rdparty.csv.cargo auditexits 0: RUSTSEC-2026-0285 is ignored, only the 9 pre-existing allowed warnings remain.