Cargo signing about community HOT 12 OPEN

as for rustup, I built this protoype so that we at least have some trust around the script which is being pulled down (and is where codedev got breached).

https://twitter.com/decodebytes/status/1404540227474046980

This works as follows.

1. Someone makes a change to rust-init.sh
2. They sign that change using sigstore (signing cert based on OIDC / entry into transparency log)
3. A commit is then made which contains the sig, signing cert and the updated script: https://github.com/lukehinds/rustup/commit/cd091d867aec7038322bfe2bc41a2bdd9235bef0
4. A release is made based on the above commit: https://github.com/lukehinds/rustup/releases/tag/v1.0

This is then what happens in the background.

curl -s -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/lukehinds/rustup/releases/latest | jq '.tag_name'
"v1.0"
curl -s -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/lukehinds/rustup/git/ref/tags/v1.0 |jq '.object'|grep sha
  "sha": "cd091d867aec7038322bfe2bc41a2bdd9235bef0",
curl -s -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/lukehinds/rustup/commits/cd091d867aec7038322bfe2bc41a2bdd9235bef0 |
 jq '.files'

The nice thing then is we have even more trust guarantees. The signing event is stored into github repo, which in turn has its own security controls (uses need 2FA) etc. We then have sigstore which adds even more layers, a maintainer uses an ODIC account to sign (no long term management of private keys). The signing event gets recorded into a public transparency log.

from community.

As a general thought: the crates.io team seems pretty overworked right now just keeping the lights on. It's probably not a good time to put anything more on their plate.

I think an interesting way to move forward here that will at least temporarily avoid integration headaches with cargo would be to prototype something like TUF + cargo as an external tool, possibly leveraging the work in something like rust-tuf or rough, or just doing sigstore verification in a manner similar to Go's sumdb.

Such a tool could take care of things like updating the crates.io index (e.g. checking the latest index is indexed in something like sigstore, then updating the local index using something like the crates-index crate) as well as downloading dependencies which aren't already in the local crate cache and verifying they also have a hash indexed in something like sigstore.

You could imagine a tool that exposes the same UI as cargo, but handles doing verified index updates/crate downloads, then drives cargo with the --offline flag.

from community.

Something else I suggested on the call was that rustup might be a better starting point, and actually plays nicely into a story for cargo/crates.io.

One thing I've gotten out of discussions with some core devs is that they'd like to have a single trust root for rustup, Rust releases/channels, and crates.io, and in that regard rustup is a great place to start as it could also bootstrap the root keys for cargo.

Here's a relevant issue: rust-lang/rustup#2028

I think this would be a pretty interesting application of sigstore: rustup self update could check sigstore to ensure that new releases it's about to install are included.

from community.

I think an interesting way to move forward here that will at least temporarily avoid integration headaches with cargo would be to prototype something like TUF + cargo as an external tool, possibly leveraging the work in something like rust-tuf or rough, or just doing sigstore verification in a manner similar to Go's sumdb.

Regarding this, here's a WIP tool which roughly fits this bill: https://github.com/kutometa/carnet

from community.

Appears to be pointed at Cloudfront:

$ host sh.rustup.rs
sh.rustup.rs is an alias for dks7yomi95k2d.cloudfront.net.

Beyond that, I'm not sure.

from community.

I will add to the above as more information comes in and I have had some time to look at cargos infra and code. Please do chime in with any views or any other historically useful threads..

My own view on this matter is that the rust community are stuck in the quandary of wanting the best approach (which of course they should be driving for), but as a result perfect is becoming the enemy of good and they have spent around 5-6 years running infra with no cryptographic guarantees of its packages.

from community.

Sorry for the inaction @tarcieri , agree rustup is definately good a place to start here. Will take a look at carnet

from community.

@tarcieri et al, where does rustup currently store its artefacts (such as the shell script, windows binaries)?

from community.

rustup is designed to be used by an individual user and does not support global installation (to my knowledge).

It uses this crate to determine the user's home directory, along with CARGO_HOME and RUSTUP_HOME:

https://crates.io/crates/home

from community.

ah sorry, should have been more specific: where is the shell script (that you pipe into sh) and the blobs that the shell script pulls down get hosted (something like ec2 bucket etc)?

from community.

FYI, discussion around Sigstore and TUF for crate signing seems to be picking up:

https://internals.rust-lang.org/t/pre-rfc-using-sigstore-for-signing-and-verifying-crates/18115/2

from community.

There's now an RFC open here for signing crates with Sigstore: rust-lang/rfcs#3403

from community.