Skip to content

ci: repin fleet-ci so this repo's own deny.toml is used again - #10

Merged
h4x0r merged 2 commits into
mainfrom
ci/repin-deny-local
Aug 7, 2026
Merged

h4x0r merged 2 commits into
mainfrom
ci/repin-deny-local

Conversation

@h4x0r

@h4x0r h4x0r commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

The shared workflow's deny-config-repo input defaulted to
SecurityRonin/fleet-config, so adopting it silently replaced this repo's
supply-chain policy with the shared one. That is a real change to what
cargo deny accepts, and no adoption PR disclosed it — nobody involved knew.

Measured across the fleet when it was found: 61 of 65 adopted repos had a
stricter local config. The shared one carries 21 advisory ignores against their
ignore = [], every one a bare RUSTSEC id with no reason and no removal
condition — which the fleet's own suppression rule forbids. Among them
RUSTSEC-2023-0071 (rsa, Marvin timing attack). Several repos also went from
bans.multiple-versions = "deny" to "warn" and gained nine allowed licences.

fleet-ci now defaults to the repository's own deny.toml; opting into the shared
config is explicit. This repin picks that up, restoring the policy this repo
actually wrote.

Reassuring rather than alarming: before this fix all 65 adopted repos were
re-checked against their OWN deny.toml and all 65 passed. The gate was weakened,
but nothing was hiding behind it. If this repin does turn a check red, that is a
true finding this repo's own policy always meant to catch — fix it rather than
re-pointing at the shared config.

Only the pinned SHA changes.

h4x0r added 2 commits August 7, 2026 09:27
The shared workflow's `deny-config-repo` input defaulted to
SecurityRonin/fleet-config, so adopting it silently replaced this repo's
supply-chain policy with the shared one. That is a real change to what
`cargo deny` accepts, and no adoption PR disclosed it — nobody involved knew.

Measured across the fleet when it was found: 61 of 65 adopted repos had a
stricter local config. The shared one carries 21 advisory ignores against their
`ignore = []`, every one a bare RUSTSEC id with no reason and no removal
condition — which the fleet's own suppression rule forbids. Among them
RUSTSEC-2023-0071 (rsa, Marvin timing attack). Several repos also went from
`bans.multiple-versions = "deny"` to `"warn"` and gained nine allowed licences.

fleet-ci now defaults to the repository's own deny.toml; opting into the shared
config is explicit. This repin picks that up, restoring the policy this repo
actually wrote.

Reassuring rather than alarming: before this fix all 65 adopted repos were
re-checked against their OWN deny.toml and all 65 passed. The gate was weakened,
but nothing was hiding behind it. If this repin does turn a check red, that is a
true finding this repo's own policy always meant to catch — fix it rather than
re-pointing at the shared config.

Only the pinned SHA changes.
`ci / Clippy` runs `cargo clippy --workspace --all-targets --all-features --
-D warnings`, which promotes `clippy::doc_markdown` to an error. Two doc lines
named the Unicode property `General_Category` unbackticked while backticking
`White_Space` and `Cf` on the same line, so clippy flagged the inconsistency:

  src/inspect.rs:350  error: item in documentation is missing backticks
  src/text.rs:426     error: item in documentation is missing backticks

Applied clippy's own suggestion, which also makes the three property names on
those lines render consistently. No `#[allow]` — the lint is correct here.

Worth noting for anyone reproducing: a bare `cargo clippy` reports these as
warnings and exits 0. Only the job's own `-- -D warnings` turns them into the
error CI sees.

Control (revert -> fail -> restore), same commit, same command:
  with fix     -> exit 0, 0 errors
  fix reverted -> exit 101, 2 doc_markdown errors
  restored     -> exit 0
`cargo fmt --check` clean.

Only `ci / Clippy` was in scope; no other check was touched.
@h4x0r
h4x0r merged commit aa66b03 into main Aug 7, 2026
16 checks passed
@h4x0r
h4x0r deleted the ci/repin-deny-local branch August 9, 2026 15:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant