Repository navigation
Check advisories with cargo-deny instead of the audit-check action - #3
Merged
Merged
Conversation
The `Dependency advisories` job ran rustsec/audit-check with its own copy of
the four ignored RUSTSEC ids and a comment asking whoever touched either list
to keep them in step. Reading the action at its pinned SHA turned up two
limits that no configuration of it fixes:
- On a `schedule` event it reports by filing an issue and returns without
ever failing the job, so a new advisory produced a green weekly run and
an issue, never a red build.
- It hard-codes a skip for yanked crates, logging "was yanked, but no issue
will be reported about it" and carrying on. A yanked dependency produced
no issue, no failure, and one buried log line.
The second gap was live: async-executor 1.14.0 was yanked and the 2026-11-09
sweep passed green and silent on it.
`cargo deny check advisories` has neither limit. The evaluation behind the
swap, against cargo-deny 0.20.2 -- both what is installed here and the newest
published version, so what CI's `cargo install cargo-deny --locked` gets:
- Advisories fail the build. With the ignore list emptied the check exits 1
and names exactly the four advisories the action was ignoring; with the
list intact it exits 0.
- Yanked crates fail once `yanked = "deny"` is set. The default is only a
warning. Run against the pre-bump lockfile, the config committed here
exits 1 on async-executor 1.14.0 -- the sweep that went green.
- A stale ignore is reported as `advisory-not-detected`, so the list now
says when an entry is ready to be pruned instead of leaning on someone
to recheck upstream.
- Scope defaults needed pinning, and this is the one way the swap could
have quietly weakened things. `unmaintained` defaults to "all", which is
what the four transitive ignores need, but `unsound` defaults to
"workspace" -- which here means nothing is checked at all, since every
advisory we ever see is in a dependency. Both are now explicit.
- A registry index that cannot be queried is a warning, not an error, so
the stricter yanked policy cannot redden CI on a registry hiccup.
The ignore list now lives in deny.toml alone, with the reasoning beside each
id, and nothing was added to it. The job needs no token permissions, because
it reports by exiting non-zero rather than filing anything: the `checks:
write` and the `issues: write` that a2d464b added both go away with the
action, leaving the workflow-wide `contents: read`.
Licenses and advisories now share one job, a step each, since both are
cargo-deny and the slowest thing in either is building cargo-deny itself. The
advisories step runs even when the license step fails, so one run still
reports both. The weekly cron is unchanged and still reaches this job -- no
job in the workflow filters on event name -- but a new advisory now fails it
instead of filing an issue and going green.
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
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.
What does this change?
Replaces the
rustsec/audit-checkaction in the advisories job with a plaincargo deny check advisoriesstep, and makes a yanked dependency fail the build.Reading
audit-checkat its pinned SHA turned up two limits that no configurationof it fixes:
scheduleevent it reports by filing an issue and returning withoutfailing the job, so a new advisory produced a green weekly run plus an issue —
never a red build.
"was yanked, but no issue will be reported about it"and carrying on. A yanked dependency produced noissue, no failure, and one buried log line.
The second gap was live:
async-executor1.14.0 was yanked and the 2026-11-09sweep passed green and silent on it. (That bump landed separately in d45a0f0,
already on
main.)Evaluation
Measured against cargo-deny 0.20.2, which is both the newest published version
and what CI's
cargo install cargo-deny --lockedresolves to — so the tests belowreflect what CI will actually run:
audit-checkcargo deny check advisoriesci.yml, human-synceddeny.tomlonlychecks: write+issues: writescheduleyanked = "deny"advisory-not-detectedwarningProofs run locally:
advisories the action was ignoring. The list is load-bearing, not decorative.
async-executor1.14.0, i.e. it catches precisely what the 2026-11-09 sweeppassed green on. This is the end-to-end proof that the gap is closed.
advisories ok, exit 0, no warnings.cargo deny check licensesstill ok.One finding a reviewer should know
[advisories]scope defaults in cargo-deny are asymmetric, and this is the oneway the swap could have quietly weakened things:
unmaintaineddefaults to"all"— fine, and load-bearing here, since all fourignored ids are transitive unmaintained advisories.
unsounddefaults to"workspace"— narrower than cargo-audit. For this repothat means nothing is checked at all, because every advisory we ever see is in a
dependency.
Both are now pinned explicitly in
deny.toml. Please don't simplify them away later.Relatedly,
IndexFailure("unable to check for yanked crates") isSeverity::Warningin cargo-deny, so the stricter yanked policy cannot redden CI on a registry
hiccup. The flip side is that a yanked crate could slip by on a warning if the
index is unreachable — still strictly more than
audit-check, which never reportsyanked at all.
Job layout
Licenses and advisories now share one job (
Licenses and advisories), a step each,since both are cargo-deny and the slowest thing in either is building cargo-deny
itself. The advisories step carries
if: ${{ !cancelled() }}so a license failuredoesn't hide it — that was the only real cost of folding. Renaming the job is safe
because
mainhas no branch protection, so there are no required-status-check namesto preserve.
The weekly cron is unchanged and still reaches this job (no job filters on event
name), but a new advisory now fails it instead of filing an issue and going green.
The
checks: writeandissues: writeadded in a2d464b both go away with theaction, leaving the workflow-wide
contents: read.The four documented ignores are unchanged and nothing was added to them.
Checklist
cargo fmtis cleancargo clippy --all-targets --releaseis warning-freecargo test --releasepassesonly
.github/workflows/ci.ymlanddeny.toml, no Rust sourceNote on the checklist: clippy and the release test suite were run locally on macOS
and both pass, but this PR changes no Rust code, so CI on Linux is the signal that
matters here — in particular the renamed
Licenses and advisoriesjob.