What's wrong
ci.yml line 223 installs the FuSa tooling as:
cargo install --git https://github.com/SoundMatt/rust-FuSa rsfusa --locked
with no --tag/--rev/--branch pin of any kind. CI job logs show this has already caused observed version drift across cache runs:
Installing rsfusa v0.3.14 (...#1dfdea52)
Replaced package `rsfusa v0.3.8 (...#4cd0d050)` with `rsfusa v0.3.14 (...#1dfdea52)`
i.e. the exact same workflow step resolved to two different versions of rsfusa on different runs, purely because rust-FuSa's default branch moved. As of a fresh check against rust-FuSa's current releases, CI is running the latest v0.3.14 right now — but this is incidental; nothing pins it there.
Why it matters
For a crate whose safety-evidence pipeline (traceability, HARA, release lifecycle — see the other conformance issues filed this session) depends entirely on rsfusa's behavior, an unpinned tool version means the safety-evidence output is not reproducible: a future rust-FuSa release could silently change trace-warning thresholds, HARA schema expectations, or release-artifact generation, and CI would pick it up with no changelog review, no PR diff, and no way to reproduce a past CI run's exact tool behavior later.
Suggested fix
Pin the install to a specific tag or rev, e.g. cargo install --git https://github.com/SoundMatt/rust-FuSa rsfusa --tag v0.3.14 --locked, and bump that pin deliberately (with a changelog check) when upgrading.
Filed from the RELAY ecosystem audit (2026-07-29), category: xfusa-currency, severity: high.
What's wrong
ci.ymlline 223 installs the FuSa tooling as:with no
--tag/--rev/--branchpin of any kind. CI job logs show this has already caused observed version drift across cache runs:i.e. the exact same workflow step resolved to two different versions of
rsfusaon different runs, purely because rust-FuSa's default branch moved. As of a fresh check againstrust-FuSa's current releases, CI is running the latestv0.3.14right now — but this is incidental; nothing pins it there.Why it matters
For a crate whose safety-evidence pipeline (traceability, HARA, release lifecycle — see the other conformance issues filed this session) depends entirely on
rsfusa's behavior, an unpinned tool version means the safety-evidence output is not reproducible: a futurerust-FuSarelease could silently change trace-warning thresholds, HARA schema expectations, or release-artifact generation, and CI would pick it up with no changelog review, no PR diff, and no way to reproduce a past CI run's exact tool behavior later.Suggested fix
Pin the install to a specific tag or rev, e.g.
cargo install --git https://github.com/SoundMatt/rust-FuSa rsfusa --tag v0.3.14 --locked, and bump that pin deliberately (with a changelog check) when upgrading.Filed from the RELAY ecosystem audit (2026-07-29), category: xfusa-currency, severity: high.