• Bug#1100734: debian-keyring: Many SHA-1 issues found by =?UTF-8?Q?=C2=A

    From Guillem Jover@21:1/5 to All on Tue Mar 18 02:30:02 2025
    Package: debian-keyring
    Version: 2024.09.22
    Severity: important

    Hi!

    The current keyrings generate many SHA-1 issues when running them through
    the Sequoia-PGP certificate linter. This means that tools that are
    starting to use Sequoia commands as OpenPGP backends, or possibly other implementations via the SOP CLI, might fail. For example dscverify,
    dpkg-source or dupload, or even when using things like sq directly.

    Running the linter over the current keyrings in the package gives the
    following summary:

    $ sq cert lint </usr/share/keyrings/debian-keyring.gpg
    […]
    Examined 924 certificates.
    0 certificates are invalid and were not linted. (GOOD)
    924 certificates were linted.
    181 of the 924 certificates (19%) have 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)
    90 of the linted certificates were expired.
    834 of the non-revoked linted certificates have at least one non-revoked User ID:
    143 have at least one User ID protected by SHA-1. (BAD)
    81 have all User IDs protected by SHA-1. (BAD)
    792 of the non-revoked linted certificates have at least one non-revoked, live subkey:
    145 have at least one non-revoked, live subkey with a binding signature that uses SHA-1. (BAD)
    214 of the non-revoked linted certificates have at least one non-revoked, live, signing-capable subkey:
    12 certificates have at least one non-revoked, live, signing-capable subkey with a strong binding signature, but a backsig that uses SHA-1. (BAD)

    $ sq cert lint </usr/share/keyrings/debian-maintainers.gpg
    […]
    Examined 247 certificates.
    0 certificates are invalid and were not linted. (GOOD)
    247 certificates were linted.
    40 of the 247 certificates (16%) have 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)
    42 of the linted certificates were expired.
    205 of the non-revoked linted certificates have at least one non-revoked User ID:
    31 have at least one User ID protected by SHA-1. (BAD)
    19 have all User IDs protected by SHA-1. (BAD)
    194 of the non-revoked linted certificates have at least one non-revoked, live subkey:
    31 have at least one non-revoked, live subkey with a binding signature that uses SHA-1. (BAD)
    53 of the non-revoked linted certificates have at least one non-revoked, live, signing-capable subkey:
    3 certificates have at least one non-revoked, live, signing-capable subkey with a strong binding signature, but a backsig that uses SHA-1. (BAD)

    $ sq cert lint </usr/share/keyrings/debian-nonupload.gpg
    […]
    Examined 40 certificates.
    0 certificates are invalid and were not linted. (GOOD)
    40 certificates were linted.
    8 of the 40 certificates (20%) have 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)
    2 of the linted certificates were expired.
    38 of the non-revoked linted certificates have at least one non-revoked User ID:
    5 have at least one User ID protected by SHA-1. (BAD)
    3 have all User IDs protected by SHA-1. (BAD)
    35 of the non-revoked linted certificates have at least one non-revoked, live subkey:
    7 have at least one non-revoked, live subkey with a binding signature that uses SHA-1. (BAD)
    4 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)

    The debian-role-keys.gpg is all good.

    Checking the git repo, gives similar results, where for some things
    the git repo is worse and for others it's better.

    It would be nice to stop accepting new updates that regress on this
    front. And ideally to start a new campaign like had been done in the
    past for other issues about weak keys/certificates.

    (I think you might already know, but in any case «sq cert lint» provides
    a --fix mode that should be able to fix these issues for the owner of
    the keys.)

    Thanks,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Guillem Jover@21:1/5 to Guillem Jover on Tue Mar 18 02:40:01 2025
    Hi!

    On Tue, 2025-03-18 at 02:20:26 +0100, Guillem Jover wrote:
    (I think you might already know, but in any case «sq cert lint» provides
    a --fix mode that should be able to fix these issues for the owner of
    the keys.)

    And an additional nice documentation resource for reference, or to
    point people to could be:

    https://book.sequoia-pgp.org/lint.html

    Thanks,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=@21:1/5 to Guillem Jover on Tue Mar 18 09:50:01 2025
    Hello,

    On Tue, Mar 18, 2025 at 02:20:26AM +0100, Guillem Jover wrote:
    It would be nice to stop accepting new updates that regress on this
    front. And ideally to start a new campaign like had been done in the
    past for other issues about weak keys/certificates.

    Something like this might implement the "stop accepting new updates"
    part. It's a bit more strict than suggested because it refuses all
    updates if the new key is broken.

    diff --git a/scripts/add-key b/scripts/add-key
    index 313719fe1d48..d38437016728 100755
    --- a/scripts/add-key
    +++ b/scripts/add-key
    @@ -61,6 +61,10 @@ else
    gpg --quiet --keyserver keyserver.ubuntu.com --recv-key $1 || true
    gpg --quiet --keyserver the.earth.li --send-key $1
    fi
    +
    +echo "Inspect new key with Sequoia:"
    +sq cert lint --cert=$keyid
    +
    gpg --keyring output/keyrings/debian-keyring.gpg \
    --keyring output/keyrings/debian-nonupload.gpg --check-sigs \
    --with-fingerprint --keyid-format 0xlong 0x$keyid | \
    diff --git a/scripts/replace-key b/scripts/replace-key
    index caad4990b20e..d93ab21d977d 100755
    --- a/scripts/replace-key
    +++ b/scripts/replace-key
    @@ -39,6 +39,8 @@ gpg --no-auto-check-trustdb --options /dev/null \
    --export-options export-clean,no-export-attributes \
    --export "$newkey" > $newkeytemp

    +sq cert lint ----cert-file="$newkeytemp"
    +
    # strip leading 0x from fingerprints
    oldkey=${oldkey##0x}
    newkey=${newkey##0x}
    diff --git a/scripts/update-key b/scripts/update-key
    index 769a0805ef4d..45f3847d0cac 100755
    --- a/scripts/update
  • From Jonathan McDowell@21:1/5 to All on Thu Mar 20 10:30:02 2025
    On Tue, Mar 18, 2025 at 09:43:33AM +0100, Uwe Kleine-König wrote:
    Hello,

    On Tue, Mar 18, 2025 at 02:20:26AM +0100, Guillem Jover wrote:
    It would be nice to stop accepting new updates that regress on this
    front. And ideally to start a new campaign like had been done in the
    past for other issues about weak keys/certificates.

    Something like this might implement the "stop accepting new updates"
    part. It's a bit more strict than suggested because it refuses all
    updates if the new key is broken.

    The other problem is that "sq cert" is not available in bookworm. We
    have a requirement that we can build the keyring under a machine running stable. Recent versions of sequoia can't even be built on bookworm
    machine (they want a newer Rust compiler), so unfortunately we're not
    going to be able to build that sort of check into our pipelines until
    trixie is released and deployed in the right places.

    I see Guillem has already taken this to -devel. While I agree we want to
    get rid of SHA-1 self-signatures on keys, I'm not clear on exactly what problem this is causing with new dpkg, given that I'd expect the
    signatures it cares about are from the unaffected role keys?

    J.

    --
    ... Sleep? Isn't that some inferior replacement for caffeine?

    -----BEGIN PGP SIGNATURE-----

    iHUEARYKAB0WIQSAYP1ALvrBQa1odmMPwJuF4mk8PAUCZ9vVYgAKCRAPwJuF4mk8 PP+/AQDjtXN5/swSItGI4W5Gp6qrjVbrlFgSJ6h8HiskAViswAD/e7fSxccXoRgm p4u7P1Q9XAUZ015vidfAFP1GOuh5qwc=
    =VtJE
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Guillem Jover@21:1/5 to Jonathan McDowell on Thu Mar 20 11:00:01 2025
    Hi!

    On Thu, 2025-03-20 at 08:44:21 +0000, Jonathan McDowell wrote:
    On Tue, Mar 18, 2025 at 09:43:33AM +0100, Uwe Kleine-König wrote:
    On Tue, Mar 18, 2025 at 02:20:26AM +0100, Guillem Jover wrote:
    It would be nice to stop accepting new updates that regress on this front. And ideally to start a new campaign like had been done in the
    past for other issues about weak keys/certificates.

    Something like this might implement the "stop accepting new updates"
    part. It's a bit more strict than suggested because it refuses all
    updates if the new key is broken.

    The other problem is that "sq cert" is not available in bookworm. We
    have a requirement that we can build the keyring under a machine
    running stable. Recent versions of sequoia can't even be built on
    bookworm machine (they want a newer Rust compiler), so unfortunately
    we're not going to be able to build that sort of check into our
    pipelines until trixie is released and deployed in the right places.

    I think passing «--weak-digest SHA1 --weak-digest RIPEMD160» to the
    relevant gpg invocations might effectively do the same (?). This has
    been in effect in Dpkg::* Perl modules, and thus dpkg-source for some
    time now as well as on things like dscverify (AFAIR), and recently on
    dupload as well.

    Otherwise in bookworm the Sequoia certificate linter was available in
    the form of the sq-keyring-linter package and command.

    I see Guillem has already taken this to -devel. While I agree we
    want to get rid of SHA-1 self-signatures on keys, I'm not clear on
    exactly what problem this is causing with new dpkg, given that I'd
    expect the signatures it cares about are from the unaffected role
    keys?

    dpkg (the project) and surrounding tools are more concerned about the
    non-role keys than the role or archive keys, as those tools deal with signatures on .dsc, .changes and similar artifacts, signed directly
    by developers.

    I brought it up there after receiving #1100867, and realizing that an
    earlier report I had been pointed at (see from https://bugs.debian.org/1076223#54 onwards) was affected by the same
    issues, to try to mitigate similar confused reactions from developers.

    Thanks,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)