Right now Cargo checks that crate tarballs match the SHA256 in the index, which is good for integrity but doesn’t prove who published a crate. If crates.io or the index itself ever got compromised, Cargo wouldn’t notice as long as the checksum matched.
There’s also some fragmentation around SBOMs (software bills of materials). Tools like cargo-auditable or cargo-cyclonedx exist, but there isn’t really a small, shared library that other tools can build on.
The headache
No way to prove authenticity of crates (signatures don’t exist today).
Security tools (cargo-audit, cargo-deny, etc.) all reinvent bits of verification.
Enterprises and CI/CD setups keep asking for SBOMs + reproducibility.
The idea
I’m thinking of building a tiny crate (placeholder name: cratetrust) that just does:
verify_package(path) → today it just checks checksums, but later could handle signatures once crates.io supports them.
generate_sbom(lockfile) → turn Cargo.lock into SPDX/CycloneDX/JSON.
verify_sbom(sbom, lockfile) → confirm a build matches a given SBOM.
Nothing fancy, no policy decisions — just the basic building blocks so tools don’t each have to roll their own.
Why now?
Other ecosystems (npm, PyPI) are already dealing with supply-chain attacks.
Rust doesn’t have an official story for signing/authenticating crates yet.
A small verification/SBOM crate could help tools today and give Cargo/crates.io something to plug into later if/when signing is added.
What I’d love feedback on
Does this sound useful as a shared foundation?
Would Cargo/Infra folks consider depending on something like this if it was mature and stable enough?
Would RustSec maintainers see value in reusing it instead of duplicating logic?
I’ll probably start with a tiny prototype (checksums + SBOM gen) and share it soon.
RFC 3724 is up for signing of the Index. Discussion on that has mostly moved off the RFC as various ideas are being experimented with to see how they would turn out.
As for the cratetrust idea, I think I'm missing how this would fit into Cargo, crates.io, rustsec, etc. Cargo already verifies checksums. The signing work is planned for Cargo and crates.io. SBOMs are more for final artifacts, so we wouldn't consume them. We do want to help in creating them considering the difficulty that exists today in accurately creating an SBOM from Cargo.lock or cargo metadata, hence the RFC.
On the SBOM side: I saw the RFC #3553, and I get that Cargo itself wouldn't be generating them. What I was thinking was more of a smaller helper library that tools like cargo-sbom or cargo-auditable could share, so they're not re-implementing the same Cargo.lock / metadata parsing. Basically not Cargo doing SBOM's directly, but a common crate that sits underneath those tools.
For signing: I know that RFC 3724 is about the index, and I assume crate tarball signing would come later. I was thinking having a pluggable verification crate could handle checksums for now, then grow into signature verification once that infra shows up. That way Cargo and the ecosystems tools could share the same base instead of duplicating logic.
Just to clarify, I'm not here suggesting Cargo should take on SBOM consumption or extra scope. I was more wondering if there's room for a small foundational crate that could sit between Cargo/crates.io and the ecosystems tools. Hopefully that framing makes more sense — and apologies if I made it sound like I was suggesting Cargo should own SBOMs directly.
That sounds like an implementation detail for those tools, depending on how much they feel is left with RFC 3553.
Note that by having the Index signed, that is signing the checksums of the crates. Unsure what all is left here. Granted, I'm not a security or SBOM compliance person.
I'll admit, I'm also not quite catching this vision of what even needs to be shared between Cargo and ecosystem tools. Sharing can also be quite difficult until the requirements have been sussed out and I generally recommend duplicating logic initially as part of that process.
Thank you for your response. I can see where the overlap is here. I think you're right that some of this may be an implementation detail for SBOM tools, and index signing definitely covers more than I was accounting for.
Where I still see the gap is:
SBOM tools don't have a common foundation for parsing/verifying Cargo metadata, so they keep reimplemeting it slightly differently.
Cargo itself won't consume SBOMs, but a small crate could help avoid drift in the ecosystem and make it easier for SBOM tools to benefit from RFC 3553.
I get your point on premature sharing — maybe the best first step would be to prototype a helper library and see if tools like cargo-sbom or cargo-auditable would actually adopt it. If they do, that makes the case stronger for a shared "foundation". If not it would most likely stay project-specific.
The existing checksums are sha256. This is extremely strong. There is no known attack against this digest, especially that bypassing it would require the hardest second preimage attack.
Cargo with Cargo.lock checks these checksums and is quite safe against compromise of locked crates. IMHO there's no need for additional tools checking these checksums.
However, there's no way of verifying that a new version has been published by the same author without trusting crates-io and GitHub. This is an area that needs improvement. It's a much harder problem than checksum verification. There's been a proposal to use TUF for this, but that's been 11 years ago.
