Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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 Andreas Radke (AndyRTR) - Wednesday, 02 June 2021, 19:04 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned
Assigned To Pierre Schmitz (Pierre)
Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

This task depends upon

Comment by Eli Schwartz (eschwartz) - Friday, 23 October 2020, 14:32 GMT
I'm not sure this matters since sequoia pgp policies only affect sequoia pgp keyservers like keys.openpgp.org, and there are several reasons why these keyservers are entirely unsuitable for use in our pgp infrastructure.

And those keys do not have any actual security issues as noted in your link...
Comment by ilf (ilf) - Friday, 23 October 2020, 15:28 GMT
This is not about Sequoia. This is about the Arch master OpenPGP keys. They should probably transition to signatures with stronger hash algorithms.

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/
Comment by Morten Linderud (Foxboron) - Friday, 23 October 2020, 15:41 GMT
As noted in the email you linked; SHA1 isn't broken for this usage. I think it's wort paying attention to this when creating (new) master keys but I don't think this is currently a critical issue that needs to be addressed.

I guess we can do a better job of handing out better defaults for packager GnuPG keys.
Comment by ilf (ilf) - Friday, 23 October 2020, 15:47 GMT
Noone used the term "critical", this task has "Severity: Low". :)
Comment by Morten Linderud (Foxboron) - Friday, 23 October 2020, 15:50 GMT
I'm just asserting that we are on the same page. The original topic provides no context except for 2 links and no opinions what should be done.
Comment by ilf (ilf) - Friday, 23 October 2020, 16:03 GMT
One could re-sign the User-IDs that rely on SHA-1 with SHA-256+. Or maybe take the opportunity to transition to a new modern key altogether.

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.
Comment by Eli Schwartz (eschwartz) - Friday, 23 October 2020, 16:13 GMT
According to the link, even the master keys that are valid under sha1 are not exclusively so... If I understand correctly by following links these keys basically keep getting reupdated with an sha1 signature due to some kind of gnupg default for which there is an open bug report?

Will this issue naturally resolve itself if the master keys get an updated self-sig using some future version of gnupg?
Comment by ilf (ilf) - Saturday, 24 October 2020, 10:47 GMT
"The TLDR for folks using the widespread GnuPG software is that GnuPG defaults to protecting you against a new self-sig, but expert-mode makes it easy:"

gpg --expert --cert-digest-algo SHA256 --sign-key $YourKeyId

https://mailarchive.ietf.org/arch/msg/openpgp/-SZkhrDYieWaz32aIW9ElAEDjM8/
Comment by ilf (ilf) - Wednesday, 18 November 2020, 17:11 GMT
There is now a tool to detect and fix these issues:

https://gitlab.com/sequoia-pgp/keyring-linter
https://crates.io/crates/sequoia-keyring-linter

Loading...