rustup: Need better sig-fail diagnostics by default. "warning: Signature verification failed" is insufficient.
When we verify the signature, we ‘correctly’ simply report success/failure, however it may be of value to report more detail by default so that if users encounter the issue seen by the OP, we can more easily diagnose the problem as often these things are transient and hard to reproduce.
ORIGINAL ISSUE
Problem
I just ran rustup update locally, and I received a warning that “signature verification failed” when downloading what appears to be the manifest for the nightly channel versions. This is the warning I received:
warning: Signature verification failed for 'https://static.rust-lang.org/dist/channel-rust-nightly.toml'
And here is the entire output from running rustup update:
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
warning: Signature verification failed for 'https://static.rust-lang.org/dist/channel-rust-nightly.toml'
info: latest update on 2020-08-18, rust version 1.47.0-nightly (792c645ca 2020-08-17)
info: downloading component 'rustfmt'
info: downloading component 'rust-src'
info: downloading component 'rust-std'
info: downloading component 'rustc'
51.5 MiB / 51.5 MiB (100 %) 32.6 MiB/s in 1s ETA: 0s
info: downloading component 'clippy'
info: downloading component 'cargo'
info: removing previous version of component 'rustfmt'
info: removing previous version of component 'rust-src'
info: removing previous version of component 'rust-std'
info: removing previous version of component 'rustc'
info: removing previous version of component 'clippy'
info: removing previous version of component 'cargo'
info: installing component 'rustfmt'
info: Defaulting to 500.0 MiB unpack ram
info: installing component 'rust-src'
info: installing component 'rust-std'
20.7 MiB / 20.7 MiB (100 %) 13.4 MiB/s in 1s ETA: 0s
info: installing component 'rustc'
51.5 MiB / 51.5 MiB (100 %) 14.7 MiB/s in 3s ETA: 0s
info: installing component 'clippy'
info: installing component 'cargo'
stable-x86_64-unknown-linux-gnu unchanged - rustc 1.45.2 (d3fb005a3 2020-07-31)
nightly-x86_64-unknown-linux-gnu updated - rustc 1.47.0-nightly (792c645ca 2020-08-17) (from rustc 1.47.0-nightly (7e6d6e5f5 2020-08-16))
info: cleaning up downloads & tmp directories
Steps
I unfortunately have not able to reproduce this bug. Running rustup update again did not give the same warning, nor did removing the nightly toolchain and installing from scratch again. I also tried moving my ~/.rustup directory to somewhere else and running rustup instlal nightly again, but I didn’t get the warning that time either. I’m a little hesitant to completely uninstall rustup and install everything from scratch again, so I figured I would wait until I heard back on this issue to see if that would be useful in some way.
Notes
This occurred on an Arch Linux box with rustup installed through the package manager.
Output of rustup --version:
rustup 1.22.1 (2020-07-08)
Output of rustup show:
Default host: x86_64-unknown-linux-gnu
rustup home: /home/saghm/.rustup
installed toolchains
--------------------
stable-x86_64-unknown-linux-gnu (default)
nightly-x86_64-unknown-linux-gnu
1.43.1-x86_64-unknown-linux-gnu
installed targets for active toolchain
--------------------------------------
x86_64-unknown-linux-gnu
x86_64-unknown-linux-musl
active toolchain
----------------
stable-x86_64-unknown-linux-gnu (default)
rustc 1.45.2 (d3fb005a3 2020-07-31)
About this issue
- Original URL
- State: open
- Created 4 years ago
- Comments: 25 (8 by maintainers)
Sorry, i think I was unclear. I ran the self update after first doing the update that showed the warnings.
I just re-ran update with this version and I see no warnings now
On Mon, Feb 6, 2023 at 1:02 PM bjorn3 @.***> wrote:
See #3185 (and https://github.com/rust-lang/simpleinfra/issues/218) for failures that started occuring today.
Same:
Seems weird to me that signature verification failures are just a warning?
UPDATE
Beta channel also fails verification:
I’m not running in a VM
I just got this now:
Interesting, I should likely increase the diagnostics on that – we’re currently opportunistically checking the GPG signature as part of the install process, I wonder if you managed to catch it before it was updated or somesuch.
At this point, there’s nothing you can do to make it easier for me to tell what happened, so I’m going to repurpose this issue.