kingchenc
c3029f2548
## Why `Supply-chain (cargo-deny)` started failing on every CI run from 2026-06-11 onward, including all five open Dependabot action-bump PRs (#266–#270), which touch no Rust code. The cause is two PyO3 advisories published 2026-06-11: | Advisory | Issue | Affected | Patched | |----------|-------|----------|---------| | RUSTSEC-2026-0176 | OOB read in `PyList`/`PyTuple` `nth`/`nth_back` | `>=0.24.0, <0.29.0` | `>= 0.29.0` | | RUSTSEC-2026-0177 | Missing `Sync` bound on `PyCFunction::new_closure` | `>=0.15.0, <0.29.0` | `>= 0.29.0` | We are on pyo3 0.28.3, so both apply. ## Why not just bump pyo3 to 0.29 The clean fix is blocked upstream: `rust-numpy` 0.28 (its latest release) hard-pins `pyo3 ^0.28.0`, so the resolver rejects 0.29 (`failed to select a version for the requirement pyo3 = "^0.28.0"`). rust-numpy's "Updated to PyO3 version 0.29.0" PR is open but not yet published to crates.io. ## Why the ignore is safe Neither vulnerable code path is reachable from our binding — verified by grep over `bindings/python/src`: no `BoundListIterator::nth`/`nth_back` or `PyTuple` equivalents (0176), no `PyCFunction::new_closure` (0177), zero `PyList`/`PyTuple` references at all. ## Removal trigger Drop both ignores once rust-numpy 0.29 lands and pyo3 is bumped to 0.29. Verified locally: `cargo deny check` → `advisories ok, bans ok, licenses ok, sources ok`.
60 lines
2.1 KiB
TOML
60 lines
2.1 KiB
TOML
# cargo-deny configuration — supply-chain checks for the Wickra workspace.
|
|
# Run locally with `cargo deny check`; CI runs the same in the `supply-chain`
|
|
# job (see .github/workflows/ci.yml).
|
|
|
|
[graph]
|
|
all-features = true
|
|
|
|
[advisories]
|
|
# Fail on any security advisory or unmaintained/unsound crate in the tree.
|
|
version = 2
|
|
yanked = "deny"
|
|
# Temporary, upstream-blocked exception. Both advisories are fixed in pyo3
|
|
# 0.29.0, but rust-numpy 0.28 (latest release) hard-pins `pyo3 ^0.28.0`, so the
|
|
# resolver cannot select 0.29 until rust-numpy ships a 0.29-compatible release
|
|
# (PyO3/rust-numpy "Updated to PyO3 version 0.29.0" is open, not yet published).
|
|
# Neither vulnerable code path is reachable from our binding: it never calls
|
|
# `BoundListIterator::nth`/`nth_back` or the `PyTuple` equivalents (0176), nor
|
|
# `PyCFunction::new_closure` (0177) — verified by grep over bindings/python/src.
|
|
# Remove both once rust-numpy 0.29 lands and the pyo3 0.29 bump goes in.
|
|
ignore = [
|
|
"RUSTSEC-2026-0176",
|
|
"RUSTSEC-2026-0177",
|
|
]
|
|
|
|
[bans]
|
|
# Catch accidental duplicate versions and wildcard ("*") version requirements.
|
|
multiple-versions = "warn"
|
|
wildcards = "deny"
|
|
# Internal workspace crates are referenced by `path` without a version, which
|
|
# is a legitimate wildcard — only flag wildcards on external registry crates.
|
|
allow-wildcard-paths = true
|
|
|
|
[licenses]
|
|
version = 2
|
|
# Licenses permitted for every crate in the dependency graph. Wickra itself is
|
|
# dual-licensed MIT OR Apache-2.0; the rest are the permissive licenses its
|
|
# dependency tree actually uses.
|
|
allow = [
|
|
"MIT",
|
|
"Apache-2.0",
|
|
"BSD-2-Clause",
|
|
"ISC",
|
|
"Unicode-3.0",
|
|
"BSL-1.0",
|
|
"Zlib",
|
|
"Unlicense",
|
|
]
|
|
# Crates whose SPDX expression carries a license exception (e.g. the LLVM
|
|
# exception on Apache-2.0). The exception is only granted to the named crate.
|
|
exceptions = [
|
|
{ allow = ["Apache-2.0 WITH LLVM-exception"], crate = "target-lexicon" },
|
|
]
|
|
|
|
[sources]
|
|
# Only the canonical crates.io registry is allowed; no git or alternative
|
|
# registries.
|
|
unknown-registry = "deny"
|
|
unknown-git = "deny"
|
|
allow-registry = ["https://github.com/rust-lang/crates.io-index"]
|