reusable-ci-rust.yml defaults enable-deny to true, and every caller in the org overrides it to false:
| Repo |
Rust surface |
deny.toml |
| Kit |
21 shared crates |
none |
| FerrFlow-Cloud |
api |
none |
| FerrGrowth-Cloud |
api |
none |
| FerrLabs-Cloud |
api (central auth/billing) |
none |
| FerrAgents (FerrFleet) |
api |
none |
| FerrTrack-Cloud |
api |
none |
| FerrLens-Cloud |
api |
none |
| FerrGames-Discord |
bot |
none |
Only the FerrFlow CLI ships one. FerrVault-Cloud is being fixed in FerrVault-Cloud#633 / FerrVault-Cloud#852, and doing it there surfaced what the rest will hit.
The consequence is that no Rust dependency tree in the org has an advisory check, a licence check or a source check in CI. Enabling it on FerrVault immediately turned up five live advisories, none of which anything would have reported. security-scan.yml does not cover this: it is secrets plus container CVEs, and the Node side has enable-audit: true while Rust has nothing.
Kit is the one to do first. Its crates are consumed by every product API, so a bad dependency there reaches all of them, and it currently has the weakest gate of the lot.
Two things every adopter needs that the snippet did not carry, both fixed by the PR attached to this issue:
sparse+https://crates.ferrlabs.com/api/v1/crates/ in allow-registry. With unknown-registry = "deny" and only crates.io listed, every ferrlabs-* crate is rejected outright.LicenseRef-FerrLabs-Proprietary and CDLA-Permissive-2.0 in the licence allowlist. The first is what the Kit crates declare, the second is webpki-roots, which turns up in anything doing TLS.
Adopting is then per repo: copy the snippet next to the crate, run cargo deny check, and either fix or document what it finds. Expect a real baseline of ignores in anything using the AWS SDK, for the reason in FerrVault-Cloud#851.
Worth stating plainly: a baseline of documented ignores is not the goal, it is the price of turning the gate on today. The value is that everything new lands on a red build instead of silently.
reusable-ci-rust.ymldefaultsenable-denytotrue, and every caller in the org overrides it tofalse:deny.tomlapiapiapi(central auth/billing)apiapiapiOnly the FerrFlow CLI ships one. FerrVault-Cloud is being fixed in FerrVault-Cloud#633 / FerrVault-Cloud#852, and doing it there surfaced what the rest will hit.
The consequence is that no Rust dependency tree in the org has an advisory check, a licence check or a source check in CI. Enabling it on FerrVault immediately turned up five live advisories, none of which anything would have reported.
security-scan.ymldoes not cover this: it is secrets plus container CVEs, and the Node side hasenable-audit: truewhile Rust has nothing.Kit is the one to do first. Its crates are consumed by every product API, so a bad dependency there reaches all of them, and it currently has the weakest gate of the lot.
Two things every adopter needs that the snippet did not carry, both fixed by the PR attached to this issue:
sparse+https://crates.ferrlabs.com/api/v1/crates/inallow-registry. Withunknown-registry = "deny"and only crates.io listed, everyferrlabs-*crate is rejected outright.LicenseRef-FerrLabs-ProprietaryandCDLA-Permissive-2.0in the licence allowlist. The first is what the Kit crates declare, the second iswebpki-roots, which turns up in anything doing TLS.Adopting is then per repo: copy the snippet next to the crate, run
cargo deny check, and either fix or document what it finds. Expect a real baseline of ignores in anything using the AWS SDK, for the reason in FerrVault-Cloud#851.Worth stating plainly: a baseline of documented ignores is not the goal, it is the price of turning the gate on today. The value is that everything new lands on a red build instead of silently.