ci: commit Cargo.lock so cargo vet can run#32
Merged
Conversation
cargo vet invokes `cargo metadata --locked`, which requires a committed Cargo.lock matching Cargo.toml. With Cargo.lock gitignored, the Security workflow has been failing for ~10 days with: ERROR `cargo metadata` exited with an error: the lock file Cargo.lock needs to be updated but --locked was passed Modern Rust guidance is to commit Cargo.lock for any crate that ships artifacts (we ship a cdylib/staticlib consumed by cachekit-py) or runs supply-chain CI (vet, audit, deny). The "libraries skip the lockfile" rule predates these tools. Changes: - Remove Cargo.lock from .gitignore - Commit Cargo.lock (155 resolved packages) - Regenerate supply-chain/config.toml exemptions to match the lockfile (versions had drifted since March) Local: `cargo vet` → Vetting Succeeded (156 exempted), exit 0.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughRemoves ChangesSupply Chain and Build Configuration
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
supply-chain/config.toml (1)
342-345:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd/track a cargo-vet audit for
ring0.17.14 (Q1 2026 priority has passed).
supply-chain/config.tomlexemptsring0.17.14 with “Audit priority Q1 2026”, butsupply-chain/audits.tomlcontains no audit entries (only[audits]) forring/0.17.14. Update by either adding a full audit entry forring0.17.14 (viacargo vet add-audit) or updating the exemption notes with a new timeline if the audit isn’t completed yet.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@supply-chain/config.toml` around lines 342 - 345, The exemption for [[exemptions.ring]] with version "0.17.14" lists "Audit priority Q1 2026" but there is no corresponding audit entry in supply-chain/audits.toml; either add a proper cargo-vet audit entry for ring 0.17.14 (use cargo vet add-audit to produce the audit record and commit it to supply-chain/audits.toml) or update the exemption notes to a new, accurate timeline/status if the audit is still pending, and ensure the exemption references ring 0.17.14 so reviewers can cross-check the audits file.
🧹 Nitpick comments (1)
supply-chain/config.toml (1)
1-635: Consider a phased audit plan for high-priority dependencies.With 156 exemptions, the majority of the dependency tree is unvetted. While this PR correctly fixes the immediate CI breakage by syncing exemptions with the committed Cargo.lock, consider establishing a phased audit strategy:
- Immediate priority: Security-critical crates (cryptography, unsafe code, FFI boundaries)
- High priority: Transitive dependencies of security-critical code paths
- Medium priority: Build-time dependencies and proc-macros
- Deferred: Leaf dependencies with minimal code surface
Tools like
cargo vet inspectcan help triage the audit workload by highlighting crates with significant unsafe code or high transitive reach.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@supply-chain/config.toml` around lines 1 - 635, Add a phased audit plan by annotating high-risk exemptions and documenting rollout: update the cargo-vet config (section [cargo-vet] and the [[exemptions]] entries) to add an "audit_priority" or "priority" metadata (e.g. set audit_priority = "immediate" for [[exemptions.ring]] and other crypto/FFI/unsafe crates), mark transitive security-critical crates as "high", proc-macros/build deps as "medium", and leaf libs as "deferred"; add a short audit roadmap comment at top of the file describing the four phases and include a one-line instruction to run "cargo vet inspect" to triage and generate the initial audit queue.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@supply-chain/config.toml`:
- Around line 10-20: The config currently marks core crypto crates
(exemptions.aead, exemptions.aes, exemptions.aes-gcm and the ring entry at
0.17.14) as criteria = "safe-to-deploy" without audit evidence; update each
crypto exemption to either include an evidence field with links to completed
audit reports/PRs/issues (for example add an "evidence" or "audit_link"
attribute referencing the audit documents) or change the criteria value to a
more appropriate risk posture (e.g., "requires-audit" or "restricted") and add a
TODO with the expected audit deadline; ensure the ring entry explicitly
references the completed audit or is downgraded from "safe-to-deploy" until
audit links are provided.
---
Outside diff comments:
In `@supply-chain/config.toml`:
- Around line 342-345: The exemption for [[exemptions.ring]] with version
"0.17.14" lists "Audit priority Q1 2026" but there is no corresponding audit
entry in supply-chain/audits.toml; either add a proper cargo-vet audit entry for
ring 0.17.14 (use cargo vet add-audit to produce the audit record and commit it
to supply-chain/audits.toml) or update the exemption notes to a new, accurate
timeline/status if the audit is still pending, and ensure the exemption
references ring 0.17.14 so reviewers can cross-check the audits file.
---
Nitpick comments:
In `@supply-chain/config.toml`:
- Around line 1-635: Add a phased audit plan by annotating high-risk exemptions
and documenting rollout: update the cargo-vet config (section [cargo-vet] and
the [[exemptions]] entries) to add an "audit_priority" or "priority" metadata
(e.g. set audit_priority = "immediate" for [[exemptions.ring]] and other
crypto/FFI/unsafe crates), mark transitive security-critical crates as "high",
proc-macros/build deps as "medium", and leaf libs as "deferred"; add a short
audit roadmap comment at top of the file describing the four phases and include
a one-line instruction to run "cargo vet inspect" to triage and generate the
initial audit queue.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: a25d67fa-1d60-4db5-a071-87af269f056d
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (2)
.gitignoresupply-chain/config.toml
💤 Files with no reviewable changes (1)
- .gitignore
Comment on lines
+10
to
+20
| [[exemptions.aead]] | ||
| version = "0.5.2" | ||
| criteria = "safe-to-deploy" | ||
|
|
||
| [[exemptions.aes]] | ||
| version = "0.8.4" | ||
| criteria = "safe-to-deploy" | ||
|
|
||
| [[exemptions.aes-gcm]] | ||
| version = "0.10.3" | ||
| criteria = "safe-to-deploy" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check for security advisories in newly exempted cryptographic crates.
echo "Checking cryptographic crates for security advisories..."
crates=("aead:0.5.2" "aes:0.8.4" "aes-gcm:0.10.3" "cipher:0.4.4" "ctr:0.9.2" "ghash:0.5.1" "polyval:0.6.2" "universal-hash:0.5.1" "inout:0.1.4")
for crate_version in "${crates[@]}"; do
IFS=':' read -r crate version <<< "$crate_version"
echo "Checking $crate $version..."
gh api graphql -f query="
{
securityVulnerabilities(first: 10, ecosystem: RUST, package: \"$crate\") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}" | jq -r ".data.securityVulnerabilities.nodes[] | select(.vulnerableVersionRange | test(\"$version\")) | \"VULNERABLE: \(.advisory.severity) - \(.advisory.summary) (patched in \(.firstPatchedVersion.identifier // \"none\"))\""
doneRepository: cachekit-io/cachekit-core
Length of output: 352
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# 1) Confirm ring audit note in supply-chain/config.toml
echo "== ring note =="
rg -n '"ring"|\bring\b|Audit priority|Q1 2026' supply-chain/config.toml || true
# print a small surrounding window if a ring match exists
line=$(rg -n '"ring"|Audit priority|Q1 2026' supply-chain/config.toml | head -n1 | cut -d: -f1 || true)
if [ -n "${line:-}" ]; then
start=$((line-15)); end=$((line+15));
sed -n "${start},${end}p" supply-chain/config.toml | nl -ba | sed 's/^/ /'
fi
# 2) Extract the specific exemption blocks for crypto crates listed
echo
echo "== crypto exemptions (criteria) =="
for c in aead aes aes-gcm cipher ctr ghash polyval universal-hash inout; do
echo "-- $c --"
rg -n "\\[\\[exemptions\\.${c}\\]\\]" -n supply-chain/config.toml || true
# Print a short block around each header
rg -n "\\[\\[exemptions\\.${c}\\]\\]" supply-chain/config.toml | while IFS=: read -r ln _; do
start=$((ln-2)); end=$((ln+6));
sed -n "${start},${end}p" supply-chain/config.toml | nl -ba | sed 's/^/ /'
done
done
# 3) Check Cargo crate-type (cdylib/staticlib) if available
echo
echo "== Cargo crate-type =="
ls -1 Cargo.toml 2>/dev/null || true
if [ -f Cargo.toml ]; then
rg -n "crate-type" Cargo.toml || true
rg -n "\\[lib\\]" -n Cargo.toml || true
# show lib section area
line=$(rg -n "\\[lib\\]" Cargo.toml | head -n1 | cut -d: -f1 || true)
if [ -n "${line:-}" ]; then
sed -n "${line},$((line+80))p" Cargo.toml | nl -ba | sed 's/^/ /'
fi
fiRepository: cachekit-io/cachekit-core
Length of output: 290
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== ring exemption notes (context) =="
line=$(rg -n '\\[\\[exemptions\\.ring\\]\\]' supply-chain/config.toml | head -n1 | cut -d: -f1 || true)
if [ -n "${line:-}" ]; then
start=$((line)); end=$((line+25));
sed -n "${start},${end}p" supply-chain/config.toml
else
rg -n 'exemptions\.ring|Ring cryptographic library|Audit priority' supply-chain/config.toml || true
fi
echo
echo "== crypto exemptions blocks (aead,aes,aes-gcm,cipher,ctr,ghash,polyval,universal-hash,inout) =="
for c in aead aes aes-gcm cipher ctr ghash polyval universal-hash inout; do
echo "-- $c --"
header=$(rg -n "\\[\\[exemptions\\.${c//-/\\-}\\]\\]" supply-chain/config.toml | head -n1 | cut -d: -f1 || true)
if [ -z "${header:-}" ]; then
# fallback: search literal header even with hyphens
header=$(rg -n "\\[\\[exemptions\\.${c}\\]\\]" supply-chain/config.toml | head -n1 | cut -d: -f1 || true)
fi
if [ -n "${header:-}" ]; then
start=$((header)); end=$((header+25));
sed -n "${start},${end}p" supply-chain/config.toml
else
echo "(not found in config)"
fi
done
echo
echo "== Cargo crate-type (if Cargo.toml exists) =="
if [ -f Cargo.toml ]; then
rg -n "crate-type" Cargo.toml || true
rg -n "\\[lib\\]" Cargo.toml || true
line=$(rg -n "\\[lib\\]" Cargo.toml | head -n1 | cut -d: -f1 || true)
if [ -n "${line:-}" ]; then
sed -n "${line},$((line+120))p" Cargo.toml
fi
else
echo "Cargo.toml not present at repo root in sandbox."
fiRepository: cachekit-io/cachekit-core
Length of output: 8429
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== supply-chain/config.toml: [[exemptions.ring]] block =="
line=$(rg -n '\\[\\[exemptions\\.ring\\]\\]' supply-chain/config.toml | head -n1 | cut -d: -f1)
start=$((line-3)); end=$((line+25));
sed -n "${start},${end}p" supply-chain/config.tomlRepository: cachekit-io/cachekit-core
Length of output: 127
🏁 Script executed:
#!/bin/bash
set -euo pipefail
line=$(rg -n '\\[\\[exemptions\\.ring\\]\\]' supply-chain/config.toml | head -n1 | cut -d: -f1 || true)
echo "found ring header at line: ${line:-<none>}"
if [ -n "${line:-}" ]; then
start=$((line-3)); end=$((line+35));
sed -n "${start},${end}p" supply-chain/config.toml
else
rg -n 'exemptions\.ring|Ring cryptographic library|Audit priority' supply-chain/config.toml || true
fiRepository: cachekit-io/cachekit-core
Length of output: 246
🏁 Script executed:
#!/bin/bash
set -euo pipefail
sed -n '342,370p' supply-chain/config.tomlRepository: cachekit-io/cachekit-core
Length of output: 676
Require evidence/audit for cryptographic “safe-to-deploy” exemptions (incl. ring)
supply-chain/config.toml exempts core crypto crates with criteria = "safe-to-deploy" (e.g., aead 0.5.2, aes 0.8.4, aes-gcm 0.10.3, cipher 0.4.4, ctr 0.9.2, ghash 0.5.1, polyval 0.6.2, universal-hash 0.5.1, inout 0.1.4). With ring 0.17.14 also set to safe-to-deploy, the config doesn’t show any audit basis for cryptographic correctness/side-channel properties—an elevated risk for a library built as cdylib/staticlib.
A GitHub advisory query for those exact crate:version pairs returned no matching “VULNERABLE” results, but that doesn’t replace documentation of the audit rationale/coverage. The ring note (“Audit priority Q1 2026”) is already past—either provide the completed-audit evidence and link(s), or update the exemptions/criteria so the release posture matches the risk level.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@supply-chain/config.toml` around lines 10 - 20, The config currently marks
core crypto crates (exemptions.aead, exemptions.aes, exemptions.aes-gcm and the
ring entry at 0.17.14) as criteria = "safe-to-deploy" without audit evidence;
update each crypto exemption to either include an evidence field with links to
completed audit reports/PRs/issues (for example add an "evidence" or
"audit_link" attribute referencing the audit documents) or change the criteria
value to a more appropriate risk posture (e.g., "requires-audit" or
"restricted") and add a TODO with the expected audit deadline; ensure the ring
entry explicitly references the completed audit or is downgraded from
"safe-to-deploy" until audit links are provided.
cargo-fuzz 0.13.1's published Cargo.lock pins rustix 0.36.5, which uses unstable `rustc_attrs` cfg gates that newer nightly rustc rejects: error: attributes starting with `rustc` are reserved for the rustc compiler `cargo install --locked` resolves from the package's published lockfile, not the consumer's. For a dev tool that doesn't link into shipped artifacts, fresh resolution is fine and avoids upstream lockfile rot. Pre-existing: last Quick Fuzz PR/push run was 2026-05-02 (green). Broke sometime between then and now due to nightly toolchain tightening. Surfaced on PR #32 because Quick Fuzz only runs on push/pull_request, not on the nightly cron.
The supply-chain vet job was schedule-only, so a poisoned transitive dependency could merge and sit unvetted for up to 24h before the nightly cron caught it. Running on pull_request closes that window and lets the job verify its own fixes pre-merge.
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
1 participant
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
The Security workflow has been red for ~10 consecutive nightly runs (since 2026-05-11). Root cause:
Cargo.lockis gitignored, butcargo vetrunscargo metadata --locked, which requires a committed lockfile matchingCargo.toml.Every run died here before any actual vetting:
All other Security jobs (Kani, 16 deep-fuzz targets, SBOM, attestation) were green — only the supply-chain gate was broken.
Changes
Cargo.lockfrom.gitignoreCargo.lock(155 resolved packages)supply-chain/config.tomlexemptions to match the lockfile — the exemption versions had drifted since they were last written in March, so committing the lockfile alone would still have failed vet on version mismatches.Why commit the lockfile
Modern Rust guidance is to commit
Cargo.lockfor any crate that ships build artifacts or runs supply-chain CI.cachekit-coredoes both: it ships acdylib/staticlibconsumed bycachekit-py's PyO3 FFI, and runscargo vet. Without a pinned lockfile, "vetted" only means "vetted against whatever resolved at CI time" — a poisoned transitive release could slip in between runs.Test plan
cargo vetlocally →Vetting Succeeded (156 exempted), exit 0cargo metadata --lockedsucceedsSummary by CodeRabbit