Hi! On Sun, 2025-03-23 at 18:46:37 -0400, Robert Edmonds wrote: > Guillem Jover wrote: > > Not all of these issues are equally "bad" from a Debian point of view, > > but all are probably bad for the certificate owners, as it might imply > > that people cannot verify signatures made with those certificates. In > > the Debian context that might mean emails, or signatures on artifacts > > such as .dsc or .changes. Depending on the specific problem those > > might even cause rejects from DAK. […] > > To check for the exact issues you can use the Sequoia certificate > > linter (from the «sq» package) with something like: […]
> > Fingerprint: DF3D96EEB3827820F302665C01817AB0AAF6CDAE > > UserID: Robert Edmonds <edmo...@debian.org> > > UserID: Robert Edmonds <edmo...@fsi.io> > > UserID: Robert Edmonds <edmo...@mycre.ws> > I'm not sure this analysis is completely correct. As far as I can tell, > you've flagged my key on the basis of "sq cert lint" reporting the > following output: > > $ sq cert lint --keyring /usr/share/keyrings/debian-keyring.gpg --cert > 01817AB0AAF6CDAE > Certificate 01817AB0AAF6CDAE, key 292C9BB54A4D3CBA uses a SHA-1-protected > binding signature. > Examined 1 certificate. > 0 certificates are invalid and were not linted. (GOOD) > 1 certificate was linted. > 1 of the 1 certificates (100%) has at least one issue. (BAD) > 0 of the linted certificates were revoked. > 0 of the 0 certificates has revocation certificates that are weaker > than the certificate and should be recreated. (GOOD) > 0 of the linted certificates were expired. > 1 of the non-revoked linted certificate has at least one non-revoked User > ID: > 0 have at least one User ID protected by SHA-1. (GOOD) > 0 have all User IDs protected by SHA-1. (GOOD) > 1 of the non-revoked linted certificates has at least one non-revoked, > live subkey: > 1 has at least one non-revoked, live subkey with a binding signature > that uses SHA-1. (BAD) > 0 of the non-revoked linted certificates have at least one non-revoked, > live, signing-capable subkey: > 0 certificates have at least one non-revoked, live, signing-capable > subkey with a strong binding signature, but a backsig that uses SHA-1. (GOOD) > > Error: 1 certificate have at least one issue > Since only the encryption subkey is affected, I do not believe this > problem can affect the signatures on my signed .dsc or .changes files. > I do not see any of the verification failures that you demonstrated > downthread on debian-devel when I try to verify a recent upload of mine: Sure, see the quoted text above from my original mail, perhaps I should have been more explicit, or perhaps list more cases. There are other cases for example where the SHA-1 issues are only over userids that are not being used to sign artifacts in Debian. But I still though it would be helpful to notify people of any problem that might affect them in other contexts (and it made the reporting easier as well :). > The "gpg --edit-key" instructions on the lore.kernel.org page you > linked did not work for me. (I use an OpenPGP hardware card and have not > investigated Sequoia's support for hardware keys.) > > I did find this blog post: > > https://blog.bmarwell.de/2020/11/21/fixing-old-sha1-infested-openpgp-keys.html > > And the command "gpg --quick-set-expire <key-fingerprint> 0 '*'" listed > on that page worked to replace the self-signature on the encryption > subkey. Now I have the following signature packet with "digest algo 10" > (SHA-512) rather than "digest algo 2" (SHA-1): > > # off=2850 ctb=89 tag=2 hlen=3 plen=566 > :signature packet: algo 1, keyid 01817AB0AAF6CDAE > version 4, created 1742767476, md5len 0, sigclass 0x18 > digest algo 10, begin of digest 93 60 > hashed subpkt 27 len 1 (key flags: 0C) > hashed subpkt 33 len 21 (issuer fpr v4 > DF3D96EEB3827820F302665C01817AB0AAF6CDAE) > hashed subpkt 2 len 4 (sig created 2025-03-23) > subpkt 16 len 8 (issuer key ID 01817AB0AAF6CDAE) > data: [4095 bits] Ah, thanks for the info, we can probably put this in a future FAQ or similar, then! I don't use an OpenPGP hardware card so I never had to look how to use that, but I do recall reading in the past that this should be currently supported by Sequoia-PGP (I think in theory even out of the box, but perhaps not if the keys are in the GnuPG keystore/gpg-agent, but dunno. There's also the openpgp-card-state package). In any case I'll ask around, if only to at least be able to give better help/guidance (or to provide a better FAQ entry). > With this new signature, the "sq cert lint" command does not print any > red text to the terminal now. Great! :) Thanks, Guillem
