Accept SHA1 keys and release 1.25.2

[pietroalbini]

This PR prepares the 1.25.2 rustup release, adding SHA1 to the list of hashing algorithms explicitly allowed by Sequoia. This is needed since the Rust key uses SHA1 for its own signatures, and Sequoia has a 2023-02-01 cutoff for the use of SHA1. That is resulting in signature verification failed warnings for rustup users.

[Rustin170506]

@pietroalbini The CI failed because you missing some changes from #3121. You need to add the -x arg to shellcheck.

[pietroalbini]

Thanks @hi-rustin, cherry-picked that commit too.

[Rustin170506]

Looks good to me! But I'm not familiar with the release process.
Should we merge this change back to the master? I'm not sure. It would be nice if Daniel had time to look at it.

[Rustin170506]

The CI failed because of the code format.

[kinnison]

Modulo Neil's concern I'm okay with this. @hi-rustin I trust you to confirm the CI tweaks are OK, as for release process, Pietro knows what to do, and once things are settled on the release, merging the changes back into master can happen.

Then we can consider how to resolve this longer term in a better fashion.

[g2p]

Updating the embedded key might be a better option:

It should be possible (for someone with the secret key) to regenerate the internal signatures without updating the key id, using this sequoia tool: https://gitlab.com/sequoia-pgp/keyring-linter (https://lib.rs/crates/sequoia-keyring-linter)

[pietroalbini]

Also disabled Clippy since 1.67 included a loooooooot of warnings.

[kinnison]

Updating the embedded key might be a better option:

It should be possible (for someone with the secret key) to regenerate the internal signatures without updating the key id, using this sequoia tool: https://gitlab.com/sequoia-pgp/keyring-linter

I think that this is a good idea, but probably might take longer to be confident about given the lack of experience with OpenPGP in the team right now.

As a plan I'd say "do this patch now, update key later, do new release with new key, and then make rollover plans properly" would make the most sense - we need to do the minimal change which gets our user-base to not need to worry about the warnings until we can protect them more fully - as it stands, we're still only warning, not erroring out, so the relative attack surface vs. protection aspects are semi-moot points anyway IMO.

[Rustin170506]

Also disabled Clippy since 1.67 included a loooooooot of warnings.

I suppose the warnings would not break the rustup's CI.

[pietroalbini]

I suppose the warnings would not break the rustup's CI.

Oh yeah, didn't notice rustup's CI doesn't deny warnings. Also pushed a super hacky way to get the Android CI hopefully working.

[pietroalbini]

CI seems to be going, will merge this to let the build on stable finish sooner.