Integrate SLSA ("Supply-chain Levels for Software Artifacts") support

[rugk]

Problem

Any software can introduce vulnerabilities into a supply chain. As a system gets more complex, it’s critical to already have checks and best practices in place to guarantee artifact integrity, that the source code you’re relying on is the code you’re actually using. Without solid foundations and a plan for the system as it grows, it’s difficult to focus your efforts against tomorrow’s next hack, breach or compromise.

from https://slsa.dev/

Proposed Solution

SLSA is in essence a framework/specification/ for software supply chain security.

SLSA seems to be a big industry effort on getting to deal with supply-chain security, which has never been done before in that essence AFAIK: https://openssf.org/press-release/2023/04/19/openssf-announces-slsa-version-1-0-release/

There is a big theory block to unpack, and I also have not yet gotten it all and also think this is quite… huge…, but in general it makes sense: There are many risks associated and we of course target the OSS use case here though in general.

• in general everything is about publishing attestations about how the software was built, in the end to a public source like this
• there are different security levels
• you may have seen projects like Docker etc. currently implementing support for it

(mostly copied from another project)

Notes

There has been previous discussion here about that. But I wanted to raise it as an issue, as it seems(?) to be getting the most popular or (currently) the one that is working best right now.

This is heavily related to rust-lang/crates.io#75 / sigstore/community#25

To get to this topic more easily the first step may actually not be cargo integration, but…

• writing a builder for rust projects, so they can publish provenance outside of that world.
• actually getting the cargo build to publish provenance in the first step (which is a different issue IMHO, so feel free to track it in a different issue)

[link2xt]

This should be split into separate actionable issues. Part of SLSA is supporting "trusted publishers", i.e. allowing GitHub to authenticate using OIDC and upload built packages with a record of GitHub Actions workflow used. npm and PyPI already support this. This sholud be a crates.io issue, not cargo issue.

Crate signatures don't seem to be necessary. npm and PyPI also don't verify any kind of signatures of downloaded packages. Checking that package was built with an audited workflow or reproducing the package before adding its hash to lockfile is enough.

[rugk]

Sure, do that, I guess we can keep this issue as a meta issue? I am not very much in the details of crate etc., but given recent incidents I guess this topic get's more important/attention, because SLSA is, IMHO, a partial solution or at least the best technical solution we can get for this issue…

[aquint-zama]

npm and PyPI also don't verify any kind of signatures of downloaded packages

It seems npm now supports slsa provenance file natively. Creating the provenance file and checking the provenance of an installed package is supported from npm command line (see publishing and auditing). Could be very nice to have the same behaviour with cargo.

I'm currently trying to create provenance file manually but I have some issues linked to the files inserted into the crate before uploading like Cargo.toml.orig (related to this issue)

[ehuss]

Thanks for the suggestion! The cargo team discussed this and decided to close this issue for now. Something like this would probably need a deeper discussion through something like internals or the RFC process to dig into exactly what is being proposed, and to discuss that proposal.