rustup installation with embedded database of sha256 hashes for known releases and targets.

[ibukanov]

Problem you are trying to solve

In case when a strict reproducibility of all tools is required rustup cannot be used to install rust or maintain Rust installations and targets. The problem is that rustup does not verify that a file it downloads is exactly what is expected.

Note under such requirements one cannot just verify that a downloaded file was signed or matches a checksum downloaded from some internet archive as that does not prevent tampering with the files or check sums. What is necessary is for rustup to use a off-line database of sha256 checksums.

Solution you'd like

It would be nice if the rustup installation includes a database of known rust releases so far. Then to get cryptographically strong assurance that rust up is installs only known files one first verifies sha256 or rustup itself and then asks rustup to always verify downloaded files against the checksum database from the installation.

Alternatively, such database can maintained independently from rustup and rustup can be pointed to it. Then one can verify the rustup installation and the databse have expected checksum. However version management of such database becomes non-trivial unless each published rustup release also will come with the corresponding database file.

Without such support one is forced not to use rustup but rather download and verify off-line installers manually against known checksums. However then cross-compilation setup becomes highly complicated. To archive it one is forced to download an extra full rust installer for the cross-compilation target, verify it against known checksum, extract Rust standard library files from it, pass that library using -L to rustc and hope that things will work.

Notes

No response

[djc]

I think hashes are not a good fit for this and signatures would make for a much better solution. I think the efforts in RFC 3724 will solve this class of issues, and I don't think it's worth the effort to come up with a different scheme in the meantime. See also #2028.

[ibukanov]

@djc Signatures, while extremely important, are not enough in our case. We must guarantee that software that is downloaded matches exactly what was tested/approved to all possible extend. So we cannot just trust signatures as an attacker gaining access to signing key can alter the download.

One may argue that it is pointless as we are not going to verify on the first download and blindly trust the changes. Still it eliminates many attack vectors.

[djc]

I think what you're looking for is reproducibility. Unless you have a complete threat model that shows a lack of hashes being the weakest link (taking into account the mechanism by which hashes are updated, and the additional complexity/issues that introducess), I don't think this issue is going to go anywhere.