OpenPGP certificates with SHA-1 issues in Debian keyrings

[Guillem Jover]

Hi!

A recent dupload improvement to switch from its GnuPG based OpenPGP
verification hook to use the dpkg OpenPGP multi-backend
implementation, which as a side effect got rid of a very old code path
that was ignoring some GnuPG verification failures, resurfaced an old
known problem with OpenPGP certificates with SHA-1 issues in the
Debian keyrings.

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.

I filed #1100734 against debian-keyring the other day, but to try to
help people that might get confused by the kind or errors that dupload
(or dpkg-source --require-valid-signature or dscverify) might be
emitting (I think dput-ng is strict with its OpenPGP verification and
should have already been rejecting signatures from those certificates,
although I think dput might be lenient as dupload used to be and might
let those through (?)), I've prepared a list of affected certificates
per keyring, which I'm attaching.

To check for the exact issues you can use the Sequoia certificate
linter (from the «sq» package) with something like:

$ sq cert lint --cert FINGERPRINT

To fix your certificate it should (in theory) be enough to do:

$ sq cert lint --cert FINGERPRINT --fix | gpg --import

(Given that Sequoia can transparently read from the GnuPG certstore,
and talk to gpg-agent.)

You might want to check the chapter for that at
<https://book.sequoia-pgp.org/lint.html>. If you'd prefer to use GnuPG
to fix your certificate, although in a really more tedious way, you can
follow these instructions instead:

https://lore.kernel.org/keys/***@7vf7ip6gxyvx/T/#u

(I'm also attaching the script I used to generate the lists.)

Thanks,
Guillem

[Charles Plessy]

Hi Guillem,

sorry but I am confused... can you explain at a beginner level what is the
difference between a certificate and a "key" in the sense it is used in the
Developers Reference?

Have a nice day,

Charles

[Stephan Verbücheln]

Post by Charles Plessy
sorry but I am confused... can you explain at a beginner level what
is the difference between a certificate and a "key" in the sense it
is used in the Developers Reference?

A certificate is a key with a name attached to it. So in the case of
Debian developer's PGP keys, it means the same thing.

The terminology has evolved over time in order to avoid confusion
between keys which do not have an identity attached to them (e.g. SSH
keys) and PGP keys, which technically are a collection of multiple
subkeys with a name attached to it.

Regards
Stephan

[Guillem Jover]

Hi!

Post by Charles Plessy
sorry but I am confused... can you explain at a beginner level what is the
difference between a certificate and a "key" in the sense it is used in the
Developers Reference?

Ah, sorry, the OpenPGP working group and as part of that, several of its
implementers have been trying to clarify its terminology, and AFAIUI to
make it a bit more approachable and to use terms more widely understood.

So «certificate» should be taken as a synonym with what was previously
known as «Transferable Public Key» (or «public key»), in contrast to
a «key» which is understood as a «Transferable Secret Key» (or
«secret key»). Which should better match the terminology used for
example with TLS/SSL certificates and keys.

See <https://www.rfc-editor.org/rfc/rfc9580.html#name-terminology-changes>.

(I've CCed Daniel Kahn Gillmor in case I've misrepresented or
misstated any of this though, or to give more detail/rationale if
needed. :)

Thanks,
Guillem

[Holger Levsen]

So «certificate» should be taken as a synonym with what was previously
known as «Transferable Public Key» (or «public key»), in contrast to
a «key» which is understood as a «Transferable Secret Key» (or
«secret key»). Which should better match the terminology used for
example with TLS/SSL certificates and keys.
See <https://www.rfc-editor.org/rfc/rfc9580.html#name-terminology-changes>.

https://book.sequoia-pgp.org/bckgrnd_keys_certificates.html agrees.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

During 2021 Bitcoin consumed 134 TWh in total, which is comparable to the
electrical energy consumed by a country like Argentina. It's also twice as
much as 2020. Related CO2 emissions were ~64 Megatons; enough to negate the
entire global net savings from deploying electrical vehicles world wide.

[Christoph Biedl]

Guillem Jover wrote...

Post by Guillem Jover
A recent dupload improvement to switch from its GnuPG based OpenPGP
verification hook to use the dpkg OpenPGP multi-backend
implementation, which as a side effect got rid of a very old code path
that was ignoring some GnuPG verification failures, resurfaced an old
known problem with OpenPGP certificates with SHA-1 issues in the
Debian keyrings.

Being one of those on the list, I'm even more confused than I'd be about
this anyway.

So those people you listed:

* Did they something wrong (although certainly with best intentions)?
* Are they just victim of the circumstances (versions of the software,
unhandy configuration, ...)?
* Is this a problem if apparently everything went fine in the many past
years?
* Is there a problem to come?
* Is there something they should do about it?
* Is there something they can do about it? Unless perhaps creating
a new key?
* Are measures in place newly generated keys will not suffer from
these problems?

# appears as big_question_marks

Christoph

[Guillem Jover]

Hi!

Post by Christoph Biedl
Being one of those on the list, I'm even more confused than I'd be about
this anyway.

Ok, let me try to clarify, then!

Post by Christoph Biedl
* Did they something wrong (although certainly with best intentions)?

I don't think so, or at least if they did something explicitly,
probably not wrong at the time they did it.

Post by Christoph Biedl
* Are they just victim of the circumstances (versions of the software,
unhandy configuration, ...)?

I think this is mostly due to GnuPG having had non-ideal defaults
in the past, that required for people to follow online guides to tune
their configurations to be able to generate safe keys at the time. And
it still having insecure defaults in some aspects right now.

Post by Christoph Biedl
* Is this a problem if apparently everything went fine in the many past
years?

I think there's widespread agreement that using SHA-1 in a security
context is not wise at this point in time. The problem is that when
using GnuPG this is sometimes invisible unless asked for explicitly.

There's been collective efforts to remove that from usage. For example
dpkg-source and dpkg-buildpackage have considered SHA-1 and RIPEMD160
as weak digests in signatures since 1.21.0 (2021-12), apt had done the
same for repo signatures since 1.2.8 (2016-03) but I don't see it ever
passed --weak-digest to gpgv so I think the reported problems here
would have slipped in, but it should refuse them now that it has
switched to use sqv since 2.9.19 (2024-12), and the Debian archive
too for the .dsc and .changes signatures themselves since
<https://lists.debian.org/debian-devel-announce/2017/02/msg00007.html>,
and while I had the notion that we had SHA-1 usage in the keyring, I
assumed that was mostly for inactive people. I was surprised to realize
that the archive was still allowing uploads for these keys, that's why
I also filed #1100894 for ftp.debian.org, and #1100734 for debian-keyring.


But in any case, as I mentioned on my original mail, these should
already be problematic right now. For instance (and not meaning to pick
on you, just as a practical hopefully relatable example) when replying
to this email, your signatures failed to verify for me with mutt + sq
integration [M], with:

,---
[-- PGP output follows (current time: Thu Mar 20 23:10:14 2025) --]

Error: 597308FBBDBA035D8C7C95DDC42C58EB591492FD is not valid according to the current policy, ignoring
because: No binding signature at time 2025-03-20T22:10:14Z
because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance
because: SHA1 is not considered secure since 2023-02-01T00:00:00Z
Signing key on 597308FBBDBA035D8C7C95DDC42C58EB591492FD is not bound:

Error: No binding signature at time 2025-03-20T21:00:00Z
because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance
because: SHA1 is not considered secure since 2023-02-01T00:00:00Z
0 authenticated signatures, 1 bad key.

Error: Verification failed: could not authenticate any signatures
[-- End of PGP output --]
`---

[M] https://wiki.debian.org/OpenPGP/Sequoia#mutt

Or for a recent upload for src:file, the signatures for the source
package also fail to verify:

,---
$ apt source --download-only file
[…]
# With sq as OpenPGP backend
$ dpkg-source --require-valid-signature -x file_5.46-2.dsc
No acceptable signatures found
dpkg-source: error: cannot verify inline signature for ./file_5.46-2.dsc: no acceptable signature found
# With gpg-g10code as OpenPGP backend
$ dpkg-source --require-valid-signature -x file_5.46-2.dsc
gpg: Signature made Thu Mar 13 19:46:00 2025 UTC
gpg: using RSA key 597308FBBDBA035D8C7C95DDC42C58EB591492FD
gpg: Can't check signature: No public key
dpkg-source: error: cannot verify inline signature for ./file_5.46-2.dsc: no acceptable signature found
$ k=/usr/share/keyrings/debian-keyring.gpg
$ gpgv-g10code --keyring $k file_5.46-2.dsc
gpgv: Signature made Thu Mar 13 20:46:00 2025 CET
gpgv: using RSA key 597308FBBDBA035D8C7C95DDC42C58EB591492FD
gpgv: Good signature from "Christoph Biedl (Debian) <***@manchmal.in-ulm.de>"
$ echo $?
0
$ gpgv-g10code --keyring $k --weak-digest SHA1 file_5.46-2.dsc
gpgv: Signature made Thu Mar 13 20:46:00 2025 CET
gpgv: using RSA key 597308FBBDBA035D8C7C95DDC42C58EB591492FD
gpgv: Note: signatures using the SHA1 algorithm are rejected
gpgv: Can't check signature: No public key
$ echo $?
2
$ gpgv-sq --keyring $k file_5.46-2.dsc >/dev/null
gpgv: Signature made Thu Mar 13 20:46:00 2025 +01:00
gpgv: using RSA key 597308FBBDBA035D8C7C95DDC42C58EB591492FD
gpgv: Can't check signature: Bad public key
$ echo $?
2
`---

Notice that dpkg-source already fails to verify (and it does
regardless of the OpenPGP backend it will use, as it has passed
--weak-digest SHA1 to gpg since 1.21.0).

And gpgv from GnuPG does not consider SHA-1 weak by default, while
gpgv from Sequoia does.

Post by Christoph Biedl
* Is there a problem to come?

I'd expect signatures from these keys will eventually also be rejected
on the archive side and a campaign will be done by the Keyring
Maintainers (as had been done in the past for weak DSA or <1024-bit keys
and similar). But the how and when is up those teams.

Post by Christoph Biedl
* Is there something they should do about it?

See my original mail about the recipe and links on how to fix these
problems. Once fixed they should send the fixed certificates to the
keyring.debian.org keyserver.

If they want to keep using GnuPG, they should probably check whether
their configuration file includes any option forcing SHA-1 or other
weak digests, or key lengths, etc.

Post by Christoph Biedl
* Is there something they can do about it? Unless perhaps creating
a new key?

See previous point, but no, there should be no need to generate a new
key. (This should be similar to refreshing ones key expiration for
example.)

Post by Christoph Biedl
* Are measures in place newly generated keys will not suffer from
these problems?

All the SOP implementations (sqop, rsop, gosop, pgpainless-cli) should
have secure defaults, Sequoia-PGP (sq) as well, GnuPG 2.x (gnupg, gpg)
should have also good defaults for new keys (but not for other things
as seen above, and might have unsafe old config options set). I'm not
sure about GnuPG 1.x (gnupg1), but out of caution I'd assume it does
not have good defaults. I've not checked but I'd assume rnp also has
good defaults.


I'm happy to try to address anything that seems unclear, or get
someone else who might be able to answer! And as Holger suggested
elsewhere, we can probably also create a FAQ on the wiki with some of
this to point to people.

Thanks,
Guillem

[Jonathan McDowell]

[I don't have enough time at present to fully drive this from a
keyring-maint PoV, but without any hats on I thought I'd add a couple of
extra bits of information.]

Post by Guillem Jover

Post by Christoph Biedl
Being one of those on the list, I'm even more confused than I'd be about
this anyway.

Ok, let me try to clarify, then!

Post by Christoph Biedl
* Did they something wrong (although certainly with best intentions)?

I don't think so, or at least if they did something explicitly,
probably not wrong at the time they did it.

No fault on the part of the user. Previous versions of GnuPG had
defaults whereby even if you generated a large RSA key, rather than a
1024 bit DSA key, it would use SHA-1 for UID + subkey binding
signatures. It took some explicit manual configuration before a key was
ever created to avoid this.

Post by Guillem Jover

Post by Christoph Biedl
* Is this a problem if apparently everything went fine in the many past
years?

I think there's widespread agreement that using SHA-1 in a security
context is not wise at this point in time. The problem is that when
using GnuPG this is sometimes invisible unless asked for explicitly.

My understanding is that there aren't any known attacks against SHA-1
self-sigs in OpenPGP at present. Given the issues with SHA-1 migration
away from it makes sense, but it's Sequoia making a decision to treat
SHA-1 self-sigs as no longer valid, combined with dpkg's switch to
Sequoia, that's driving the issue here.

I note that the Sequoia lint checks are not available in bookworm, you
need to use the version in trixie/sid.

Post by Guillem Jover
I'm happy to try to address anything that seems unclear, or get
someone else who might be able to answer! And as Holger suggested
elsewhere, we can probably also create a FAQ on the wiki with some of
this to point to people.

Thanks for doing this, Guillem.

J.

[Christoph Biedl]

Guillem Jover wrote...

Post by Guillem Jover
I'm happy to try to address anything that seems unclear, or get
someone else who might be able to answer! And as Holger suggested
elsewhere, we can probably also create a FAQ on the wiki with some of
this to point to people.

Thanks for your explanations, things are a lot clearer now.

Christoph

[Robert Edmonds]

Post by Guillem Jover
Hi!
A recent dupload improvement to switch from its GnuPG based OpenPGP
verification hook to use the dpkg OpenPGP multi-backend
implementation, which as a side effect got rid of a very old code path
that was ignoring some GnuPG verification failures, resurfaced an old
known problem with OpenPGP certificates with SHA-1 issues in the
Debian keyrings.
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.
I filed #1100734 against debian-keyring the other day, but to try to
help people that might get confused by the kind or errors that dupload
(or dpkg-source --require-valid-signature or dscverify) might be
emitting (I think dput-ng is strict with its OpenPGP verification and
should have already been rejecting signatures from those certificates,
although I think dput might be lenient as dupload used to be and might
let those through (?)), I've prepared a list of affected certificates
per keyring, which I'm attaching.
To check for the exact issues you can use the Sequoia certificate
$ sq cert lint --cert FINGERPRINT
$ sq cert lint --cert FINGERPRINT --fix | gpg --import
(Given that Sequoia can transparently read from the GnuPG certstore,
and talk to gpg-agent.)
You might want to check the chapter for that at
<https://book.sequoia-pgp.org/lint.html>. If you'd prefer to use GnuPG
to fix your certificate, although in a really more tedious way, you can
(I'm also attaching the script I used to generate the lists.)
Thanks,
Guillem
Fingerprint: DF3D96EEB3827820F302665C01817AB0AAF6CDAE

Hello,

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

Now, key 292C9BB54A4D3CBA is my encryption subkey, not the main key
01817AB0AAF6CDAE that is used for signing and certifying:

sec rsa4096/01817AB0AAF6CDAE
created: 2013-10-03 expires: never usage: SC
card-no: 0005 00003A89
trust: ultimate validity: ultimate
ssb rsa4096/292C9BB54A4D3CBA
created: 2013-10-03 expires: never usage: E
card-no: 0005 00003A89

Since only the encryption subkey is affected, I do not believe this
problem can affect the signatures on my signed .dsc or .changes files.

Here are the raw PGP packets, from a clean sid chroot with gpg and
debian-keyring installed:

***@7311057f397a:/# gpg --keyring=/usr/share/keyrings/debian-keyring.gpg --export-options export-minimal --export 01817AB0AAF6CDAE | gpg --list-packets
# off=0 ctb=99 tag=6 hlen=3 plen=525
:public key packet:
version 4, algo 1, created 1380802569, expires 0
pkey[0]: [4096 bits]
pkey[1]: [17 bits]
keyid: 01817AB0AAF6CDAE
# off=528 ctb=b4 tag=13 hlen=2 plen=31
:user ID packet: "Robert Edmonds <***@fsi.io>"
# off=561 ctb=89 tag=2 hlen=3 plen=543
:signature packet: algo 1, keyid 01817AB0AAF6CDAE
version 4, created 1470513048, md5len 0, sigclass 0x30
digest algo 8, begin of digest fb a2
hashed subpkt 2 len 4 (sig created 2016-08-06)
hashed subpkt 29 len 1 (revocation reason 0x20 ())
subpkt 16 len 8 (issuer key ID 01817AB0AAF6CDAE)
data: [4095 bits]
# off=1107 ctb=b4 tag=13 hlen=2 plen=33
:user ID packet: "Robert Edmonds <***@mycre.ws>"
# off=1142 ctb=89 tag=2 hlen=3 plen=570
:signature packet: algo 1, keyid 01817AB0AAF6CDAE
version 4, created 1408125108, md5len 0, sigclass 0x13
digest algo 8, begin of digest 5e 8d
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
hashed subpkt 25 len 1 (primary user ID)
hashed subpkt 2 len 4 (sig created 2014-08-15)
hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 3)
hashed subpkt 21 len 4 (pref-hash-algos: 10 9 8 11)
hashed subpkt 22 len 4 (pref-zip-algos: 2 3 1 0)
subpkt 16 len 8 (issuer key ID 01817AB0AAF6CDAE)
data: [4096 bits]
# off=1715 ctb=b4 tag=13 hlen=2 plen=35
:user ID packet: "Robert Edmonds <***@debian.org>"
# off=1752 ctb=89 tag=2 hlen=3 plen=567
:signature packet: algo 1, keyid 01817AB0AAF6CDAE
version 4, created 1408125126, md5len 0, sigclass 0x13
digest algo 8, begin of digest cc 62
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
hashed subpkt 2 len 4 (sig created 2014-08-15)
hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 3)
hashed subpkt 21 len 4 (pref-hash-algos: 10 9 8 11)
hashed subpkt 22 len 4 (pref-zip-algos: 2 3 1 0)
subpkt 16 len 8 (issuer key ID 01817AB0AAF6CDAE)
data: [4095 bits]
# off=2322 ctb=b9 tag=14 hlen=3 plen=525
:public sub key packet:
version 4, algo 1, created 1380802569, expires 0
pkey[0]: [4096 bits]
pkey[1]: [17 bits]
keyid: 292C9BB54A4D3CBA
# off=2850 ctb=89 tag=2 hlen=3 plen=543
:signature packet: algo 1, keyid 01817AB0AAF6CDAE
version 4, created 1380802569, md5len 0, sigclass 0x18
digest algo 2, begin of digest 1e e4
hashed subpkt 2 len 4 (sig created 2013-10-03)
hashed subpkt 27 len 1 (key flags: 0C)
subpkt 16 len 8 (issuer key ID 01817AB0AAF6CDAE)
data: [4095 bits]

If I understand correctly, the last packet is the only one with "digest
algo 2" (SHA-1), which is the self-signature on the encryption subkey
(292C9BB54A4D3CBA). All the other signatures are "digest algo 8"
(SHA-256).

By the way, the hash algorithm numbers are registered here:
https://www.iana.org/assignments/openpgp/openpgp.xhtml#openpgp-hash-algorithms.

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:

$ apt source --download-only protobuf-c
NOTICE: 'protobuf-c' packaging is maintained in the 'Git' version control system at:
https://salsa.debian.org/edmonds/protobuf-c.git
Please use:
git clone https://salsa.debian.org/edmonds/protobuf-c.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 538 kB of source archives.
Get:1 http://deb.debian.org/debian sid/main protobuf-c 1.5.1-1 (dsc) [2,060 B]
Get:2 http://deb.debian.org/debian sid/main protobuf-c 1.5.1-1 (tar) [532 kB]
Get:3 http://deb.debian.org/debian sid/main protobuf-c 1.5.1-1 (diff) [4,576 B]
Fetched 538 kB in 0s (8,641 kB/s)
Download complete and in download only mode

$ gpgv-sq --keyring /usr/share/keyrings/debian-keyring.gpg protobuf-c_1.5.1-1.dsc 1>/dev/null
gpgv: Signature made Sun Feb 2 00:10:24 2025 -05:00
gpgv: using RSA key DF3D96EEB3827820F302665C01817AB0AAF6CDAE
gpgv: Good signature from "Robert Edmonds <***@mycre.ws>"
gpgv: "Robert Edmonds <***@debian.org>"

$ dscverify --verbose --no-default-keyrings --keyring /usr/share/keyrings/debian-keyring.gpg protobuf-c_1.5.1-1.dsc
protobuf-c_1.5.1-1.dsc:
gpg: Signature made Sun 02 Feb 2025 12:10:24 AM EST
gpg: using RSA key DF3D96EEB3827820F302665C01817AB0AAF6CDAE
gpg: Good signature from "Robert Edmonds <***@mycre.ws>" [unknown]
gpg: aka "Robert Edmonds <***@debian.org>" [unknown]
gpg: WARNING: Using untrusted key!
Good signature found
validating protobuf-c_1.5.1.orig.tar.gz
validating protobuf-c_1.5.1-1.debian.tar.xz
All files validated successfully.

That makes sense, since only my encryption subkey is affected.

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]

With this new signature, the "sq cert lint" command does not print any
red text to the terminal now.

But, again, this is a self-signature on an encryption subkey and I do
not see how that should affect the verification of signatures made from
the signing key on .dsc, .changes, etc. files.

[Guillem Jover]

Hi!

Post by Robert Edmonds

Post by Guillem Jover
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.

[…]

Post by Robert Edmonds

Post by Guillem Jover
To check for the exact issues you can use the Sequoia certificate

[…]

Post by Robert Edmonds

Post by Guillem Jover
Fingerprint: DF3D96EEB3827820F302665C01817AB0AAF6CDAE

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
$ 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.
0 have at least one User ID protected by SHA-1. (GOOD)
0 have all User IDs protected by SHA-1. (GOOD)
1 has at least one non-revoked, live subkey with a binding signature that uses SHA-1. (BAD)
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

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 :).

Post by Robert Edmonds
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.)
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"
# 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).

Post by Robert Edmonds
With this new signature, the "sq cert lint" command does not print any
red text to the terminal now.

Great! :)

Thanks,
Guillem