Validate signatures of builds

[brson]

Right now the rust binaries are accompanies by gpg signatures, but rustup does not check them.

I don't want to bring in native dependencies unless they are dead simple to build. We should probably try the gpgme bindings first, since those would be compatible with our existing gpg keys. If that doesn't work out then we can explore more exotic options.

Previous thread.

[DemiMarie]

What about calling out to an external GPG process, like rustup.sh did?

[vks]

What about calling out to an external GPG process, like rustup.sh did?

This is what the gpgme bindings do effectively.

[brson]

cc #242

[brson]

@DemiMarie I'd rather not do that because we can't guarantee the presence of GPG, and I want everybody to get the advantage of signature validation.

[vks]

I want everybody to get the advantage of signature validation.

👍 This should not be optional, preventing downgrade attacks.

[brson]

https://pijul.org/openpgp/ may be part of the solution.

[Diggsey]

Anything involving GPG will have to be optional.

Ok, after writing both Thrussh and the OpenPGP crates, here are some thoughts:

Anything involving GPG will have to be optional.

This is a GnuPG issue. The binary called GPG changes name with different versions (which leads to really unstable situations in systems like NixOS, where it's normally called gpg2, but also sometimes gpg inside a nix-shell, depending on the channel).

First of all, I am really grateful to the the authors of OpenPGP and GnuPG for getting the world to use encryption and signatures in an almost easy way.

That said, I also realize that RFC 4880 is really unclear and ambiguous, even on really important things. GnuPG has the merit of being the main available implementation. It's also well tested and robust (despite being 200000 lines of C, not counting crypto).

However, according to my tests, GnuPG does not always include cryptographically important parts of OpenPGP, such as "modification codes", an OpenPGP feature described in the RFC, which are more commonly called MAC in other cryptography libraries. This might allow an attacker to modify an encrypted message without decrypting it.

If we try to implement OpenPGP in Rust, there are really big issues with the format, which IMHO do not make it suitable to use in applications such as rustup:

• The scope of a signature is never clearly specified. In RFC4880, hashes of "data" are signed, but "data" is never clearly defined. GnuPG apparently chose to sign the hash of the contents of files, opened in binary mode (i.e. without converting \n to CRLF). This lack of clarity in the RFC is really problematic, as it might allow an attacker to change file names in the signature of multiple files. To achieve compatibility with GnuPG, Rustup packagers would have to make sure only tar archives get signed, and would also have to describe this very clearly to downstream packagers.
• The RFC is very complicated for simple things, such as length encoding. For instance, the length of a 512 bytes RSA key can be encoded in four different format, which might allow implementations to save up to 3 bytes, compared to a simple big endian u32. And as Rust supporters probably know, it's quite easy to get array lengths wrong. If you want to achieve interoperability with the world outside Rust, you'll have to rely on C code decoding array lengths from a tricky format.

Btw, I realize there are lots of awesome C programmers out there, and the authors of the above mentioned software are clearly among them.

Btw, I'm currently thinking of a format with the same features as PGP (a web of trust using the existing infrastructure, encryption and signatures).
I'm seriously thinking of reusing the SSH RFCs, because they are really well defined, precise, well tested, and able to encrypt/sign large amount of data efficiently.

[vks]

I don't think a web of trust makes sense for rustup. You have to trust on first use anyway, so it seems much simpler and more straight forward to just use TOFU.

@vks: Before writing the OpenPGP crate, I used to believe this wasn't the case (maybe I've attended a Rust conference and signed the rustup key), and used to think that the web of trust was really cool. I'm not so sure anymore. Here is some arguments:

• https://lists.torproject.org/pipermail/tor-talk/2013-September/030235.html
• http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html

[Diggsey]

This is a GnuPG issue.

It's an issue for any method which attempts to use a user's existing web of trust to validate downloads: it's unrealistic to have that as a prerequisite to install toolchains via rustup.

As far as I'm concerned, the plan was always to just encode the public key inside the rustup binary, and have a pure-rust solution to verify the signatures of downloads against that public key. The "web of trust" only comes into play for someone installing rustup for the first time, and if they're doing that via their package manager, then even that's unnecessary.

I see. Then the best method seems to be:

1. Don't use PGP.
2. Sign with Ed25519.
3. Make it so that people organizing Rust events have a copy of the key (Ed25519 keys are really short), and show it on the first slide of the event. Key hashes are not sufficient, as demonstrated by GnuPG.

This doesn't solve everything, though: when the key or the cryptosystem is compromised, you'll have to "revoke" the key.