FS#68392 - [archlinux-keyring] 3 of the 5 master keys rely on SHA1
Attached to Project:
Arch Linux
Opened by ilf (ilf) - Friday, 23 October 2020, 13:06 GMT
Last edited by David Runge (dvzrv) - Monday, 04 September 2023, 01:27 GMT
Opened by ilf (ilf) - Friday, 23 October 2020, 13:06 GMT
Last edited by David Runge (dvzrv) - Monday, 04 September 2023, 01:27 GMT
|
Details
SHA-1 is a Shambles:
https://sha-mbles.github.io/
3 of the 5 master keys rely on SHA1: https://gitlab.com/sequoia-pgp/sequoia/-/issues/595#note_434331334 |
This task depends upon
Closed by David Runge (dvzrv)
Monday, 04 September 2023, 01:27 GMT
Reason for closing: Fixed
Additional comments about closing: None of the main key holders have SHA-1 self-signatures anymore.
Monday, 04 September 2023, 01:27 GMT
Reason for closing: Fixed
Additional comments about closing: None of the main key holders have SHA-1 self-signatures anymore.
And those keys do not have any actual security issues as noted in your link...
See these discussions for more details and background:
https://gitlab.com/sequoia-pgp/sequoia/-/issues/595
https://mailarchive.ietf.org/arch/msg/openpgp/Rp-inhYKT8A9H5E34iLTrc9I0gc/
I guess we can do a better job of handing out better defaults for packager GnuPG keys.
This has to be done by the individual owners of the private keys in question, so it's probably up to them to chose the right path.
Will this issue naturally resolve itself if the master keys get an updated self-sig using some future version of gnupg?
gpg --expert --cert-digest-algo SHA256 --sign-key $YourKeyId
https://mailarchive.ietf.org/arch/msg/openpgp/-SZkhrDYieWaz32aIW9ElAEDjM8/
https://gitlab.com/sequoia-pgp/keyring-linter
https://crates.io/crates/sequoia-keyring-linter