signature for registry files

[lightsing]

Problem

In registry, files are served with only checksum. I'm worrying about "supply chain attack" when developers are using 3rd party mirror of registry. Since registry can define custom dl link for replacing the origin aws s3.
this should not be confused with #4768.
This issues is talking about how to ensure the 3rd party mirror are serving the crates unmodified from the origin ones. #4768 is talking about how to ensure the registry are serving the crates from the original authors.

Proposed Solution

I propose to add an optional gpg signature as long as the checksum which is signed by the registry authority (in current situation, it's crates.io). Just like apt and other os package mange system does, it has a signing keyring signs the packages.

To maintain the backwards compatibility, the gpg signature should be optional but enforce for crates.io.
This is a valid record for now:

{"name":"NAME","vers":"VERSION","deps":[],"cksum":"CHECKSUM","features":{},"yanked":false}

The new record look like this:

{"name":"NAME","vers":"VERSION","deps":[],"cksum":"CHECKSUM","sig":"SIGNATURE","features":{},"yanked":false}

Notes

No response

[bjorn3]

Having a third party mirror of the registry serve malicious crates is already somewhat mitigated by the fact that the crate checksums end up in the lockfile. This means that if the lockfile contains the checksum for the clean version trying to use the malicious registry will result in an error, thus preventing the attack. If the lockfile contains the checksum for the malicious version trying to use the official (or a non-malicious) registry will cause a build issue, thus giving away the fact that the malicious registry is malicious.

[tarcieri]

Here's a previous RFC which proposed something quite similar: rust-lang/rfcs#2474

It was closed with a disposition to postpone, but there's plenty of prior discussion there.

See also: rust-lang/crates.io#75