rustup-init.exe needs to be code-signed

[alvinhochun]

rustup-init.exe (downloaded from https://win.rustup.rs/) is not signed with an EV code signing certificate. As a result, there isn't an obvious way for Windows users to verify the download. (Neither https://www.rust-lang.org/tools/install nor https://rustup.rs/ shows any gpg keys or even checksums for use.)

Moreover, the rustup-init.exe can get blocked by SmartScreen. Even though users can bypass it by clicking on "More Info" then "Run anyway", it doesn't bring any confidence.

SmartScreen operates on the basis of reputation. The SmartScreen warning might eventually go away when the rustup-init.exe gets used by more users, but it resets whenever a new version is built and published. If rustup-init.exe is code-signed, the reputation will be inherited by any programs signed with the same certificate, which should make SmartScreen happy. (See: https://blogs.msdn.microsoft.com/ie/2012/08/14/microsoft-smartscreen-extended-validation-ev-code-signing-certificates/)

[eddyp]

I agree, all official releases should be signed, ideally with keys which have a good chain of trust.

[aidanhs]

We discussed this in an infra team meeting. In summary:

• signing rustup is something that's come up before and the only reason we don't do it is we haven't got round to it
• we're open to exploring/moving forward on signing, but we can't commit to anything before understanding fully what's involved
• on the subject of understanding - we'd welcome help here! It'd be great to get an overview of the steps involved, best practices and so on to be able to see what the next steps would be if we did want to move forward

(other open questions involve things like: What about OSX signing? Does the approach we choose for rustup generalise to other binaries we distribute?)

[eddyp]

@aidanhs I have no experience with signing of Windows binaries (I have with signing packages and repositories for Debian based Linux distros), but I expect the approach to take on one binary to work on the all others on that same platform. Typically the platform specific docs should provide exact details, and automation should be possible for all, but the exact details will probably be different.

BTW, if individual binary/file signing is not possible, the second best thing is to sign the packaging format and files with checksums for each file. This is a good idea no matter what to make sure tool chains are not corrupted, infected or modified and some commands could allow verification.

[jethrogb]

@jseyfried can you share Windows binary signing best practices?

[alvinhochun]

@aidanhs

I have some slight idea on how it works. You get a code signing cert and you would invoke signtool.exe from the Windows SDK somewhere in the build/packaging process to sign the output executables (.exe/.dll).

Some interest points I can think of:

• Someone will need to purchase the cert
• There are different types of code signing cert, some of which require using a hardware token (examples: https://www.digicert.com/code-signing/ev-code-signing-compared.htm)
• The signing should be time stamped so that the signed executables will still verify after the cert is expired

If all you care is for the initial SmartScreen warning on rustup-init.exe to not appear every time a new one is released, it should be enough to only sign that and leave the installed files (e.g. rustc.exe/rust-lld.exe/rls.exe) unsigned (see note below). But since you would already have the code signing cert, there is little reason to not sign them all unless it's too tricky to implement for the Rust build infrastructure. (Consider that the keys need to be stored securely.)

To have rustup verify downloaded files would be a separate issue. though it should be possible to leverage the same Windows signing infrastructure for this purpose on Windows. The obvious downside is that it would only work on Windows unless there are cross-platform libraries and tools to support it.

---

Note: When most (if not all) browsers on Windows download a file, they add an NTFS alternate data stream Zone.Identifier to the file as a flag to mark it as "being from an untrusted zone". This practice started on Internet Explorer on Windows XP and later followed by other browsers. What I believe SmartScreen does is that it scans only the files that have the specific flag, and if the reputation passes the threshold, it would automatically remove the flag and skip the warning. If the file is not flagged in the first place (which is the case for files downloaded by rustup) SmartScreen shouldn't do anything at all.

[eddyp]

Regarding secure storage of the keys, I think a Yubikey device or something similar can do this. For instance, at EuroBSD 2018 the gift package contained a microcontroller based key storage device. The device was sponsored by Modirum and is using the Gnuk OpenPGP firmware from the Free Software Initiative of Japan and it looks like a USB stick.

[eddyp]

An update on the secure key storage, on the Gnuk project page there is a list of compatible devices, and one of them, Nitrokey Start, looks quite cheap (29€) and looks nice, comes pre-installed with all needed SW, and it seems the company has very big names as clients: Google, BBC, SuSE, Redhat, Mozilla, Nvidia, ABB, Adobe... (link to pdf).

[jethrogb]

How would a USB dongle be connected to the CI infrastructure? It seems to me a cloud-based HSMaaS solution such as SDKMS would be more convenient. We can provide a free account for the Rust project, someone from the infra team please contact me to set this up.

[kornelski]

Be careful about types of hardware keys and their software. I've got one that on every signing pops up a GUI that asks for a PIN. There's no CLI version. It doesn't work over SSH and gets in the way of build automation.

[notriddle]

signtool.exe is a PITA; I know, I've tried it.

• It doesn't run in Travis CI for Windows: https://travis-ci.community/t/codesigning-on-windows/1385

• Even when it works, it requires special permissions: https://support.comodo.com/index.php?/Knowledgebase/Article/View/1187/38/signing-microsoft-windows-user-mode-drivers

• It only runs on Windows.

The easy way to do it is osslsigncode, which can run under any platform that can run basic C code and OpenSSL.

[jethrogb]

• It doesn't run in Travis CI for Windows: https://travis-ci.community/t/codesigning-on-windows/1385

• Even when it works, it requires special permissions: https://support.comodo.com/index.php?/Knowledgebase/Article/View/1187/38/signing-microsoft-windows-user-mode-drivers

Isn't this simply a matter of trying to access the machine keystore when you should be using the user keystore?