Verify gpg signatures as part of bump-stage0

[pietroalbini]

This PR is a followup to #88362 to perform signature verification as part of bump-stage0, ensuring the manifests accessed by the tool are signed with the release team's gpg key. This grants us the advantages of signature verification without the need of performing it as part of x.py, as the pinned checksums used by x.py will be verified by bump-stage0 before they're committed.

With this PR an attacker wanting to compromise the boostrap compiler undetected would also need to compromise the signing key and wait for someone else (human or automation) to update the pinned checksums. This does not add any extra protection against an attacker submitting a PR updating the pinned checksums, as they would just avoid performing the signature verification.

The pgp crate was chosen compared to sequoia-pgp both because of licensing reasons (Sequoia is GPL) and because Sequoia relies on C dependencies (the nettle crypto library). Rustup also uses the pgp crate.

r? @Mark-Simulacrum

[kinnison]

Rustup's lack of using sequoia-pgp was because of Windows stuff, but AIUI we're close to being able to switch over to it instead of the pgp crate. IMO it'd be a good idea to use Sequoia if you can.

[rvolgers]

Rustup's lack of using sequoia-pgp was because of Windows stuff, but AIUI we're close to being able to switch over to it instead of the pgp crate. IMO it'd be a good idea to use Sequoia if you can.

SequoiaPGP is GPL 2.0, which as far as I understand makes any binary which integrates it covered by GPL 2.0, which would be functionally a license change for rustup.

Please correct me if I've misunderstood anything though.

[bjorn3]

Using it as executable instead of library would be possible I think. In that case the rustup executable doesn't become covered by GPL AFAIK, only the sequoia-pgp executable.

[kinnison]

Yes the licence concern remains. I was going to talk with Sequoia about that once I was confident the rest was sorted. We actually have a PR from them to try and start the process so I'll probably put a checklist on there and licence terms will be part of that.

[nbraud]

Could/should the release team use a much-simpler signature protocol, for instance a plain SHA256-ed25519 signature as done in OpenBSD's signify(1) tool? Not only would this resolve the licensing concern, but also remove a lot of complexity (and potential vulnerabilities) and decouple Rust's software distribution from OpenPGP's obsolete cryptography; quoting Debian's apt development team:

OpenPGP is a major disappointment for repository signing, the interfaces around being the cause for multiple security vulnerabilities; and limited development speed and deprecation of algorithms and key sizes causing uncertainty about long term safety of LTS releases.

I realise this is widely out of this PR's scope, but if licensing & distribution issues are the blocker, it might make sense to instead head directly towards the better/safer option.

[kinnison]

My argument against things like signify is that they typically sidestep the complexities of OpenPGP by lacking the capabilities of it. Most complaints about OpenPGP come from the complexity of using it well and it's arguable that can result in incorrectness, but at the same time, used properly it offers us a larger set of capabilities in an RFC defined mechanism.

[pietroalbini]

Hey all, after a quick chat with @Mark-Simulacrum we came to an agreement to investigate other ways to improve the supply chain security of Rust than this specific PR. Closing it.

Regarding ways to sign Rust distributions, I'd love to (also?) get other signature algorithms implemented, but this is probably not the right place to do so. If you all are interested in continuing a discussion on that we can probably figure out a place to do so.

[nbraud]

My argument against things like signify is that they typically sidestep the complexities of OpenPGP by lacking the capabilities of it.

Those capabilities are entirely unnecessary in this usecase. You might note for instance that the current OpenPGP signing key is simply embedded in the repository.