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

Reply via email to