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/fxotnlhsyl2frp54xtguy7ryrucuwselanazixeax3motyyoo3@7vf7ip6gxyvx/T/#u

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

Thanks,
Guillem

Fingerprint: 7733B328D2795F5BE2325ADD01509D5CAB4AFD3F
UserID: Josue Ortega (debian gpg) <[email protected]>
UserID: Josue Ortega (debian gpg) <[email protected]>
UserID: Josue Ortega <[email protected]>
UserID: Josue Ortega <[email protected]>
UserID: Josue Ortega <[email protected]>
UserID: Josue Ortega <[email protected]>

Fingerprint: DF3D96EEB3827820F302665C01817AB0AAF6CDAE
UserID: Robert Edmonds <[email protected]>
UserID: Robert Edmonds <[email protected]>
UserID: Robert Edmonds <[email protected]>

Fingerprint: 45877F1F6F591AB1F366BC3A02541A371530B71F
UserID: Gert Wollny (DM key) <[email protected]>
UserID: Gert Wollny <[email protected]>
UserID: Gert Wollny <[email protected]>

Fingerprint: DD34BB88EFB7DE735C77597C0270A2758CD736E2
UserID: Carl Chenet (MyTux) <[email protected]>
UserID: Carl Chenet <[email protected]>
UserID: Carl Chenet <[email protected]>
UserID: Carl Chenet <[email protected]>

Fingerprint: 812EEFD8A3FBA4ACE4DF114B04C53BD7FE030551
UserID: Julien Puydt (Debian) <[email protected]>
UserID: Julien Puydt <[email protected]>

Fingerprint: 2255310AD1A248A07B597638065FE53932DC551D
UserID: Geoffroy Berret <[email protected]>
UserID: Geoffroy Youri Berret <[email protected]>
UserID: Geoffroy Youri Berret <[email protected]>
UserID: Jack Kaliko (dev id) <[email protected]>

Fingerprint: 7F4BC7CC3CA06F97336BBFEB0668CC1486C2D7B5
UserID: Sebastian Dröge <[email protected]>
UserID: Sebastian Dröge <[email protected]>
UserID: Sebastian Dröge <[email protected]>
UserID: Sebastian Dröge <[email protected]>

Fingerprint: E037CB2A1A0061B943363C8B0907409606AAAAAA
UserID: Jon Dowland <[email protected]>
UserID: Jon Dowland <[email protected]>
UserID: Jon Dowland <[email protected]>
UserID: Jonathan Dowland <[email protected]>
UserID: Jonathan Dowland <[email protected]>
UserID: Jonathan Dowland <[email protected]>
UserID: Jonathan Dowland <[email protected]>

Fingerprint: FAE1E5B64652BE798E278CC20BC47DC64D135306
UserID: Andreas Henriksson <[email protected]>
UserID: Andreas Henriksson <[email protected]>

Fingerprint: 5340D001360CA656E3497EB70C48EA2A7A8FFD7B
UserID: Peter Michael Green <[email protected]>
UserID: Peter Michael Green <[email protected]>

Fingerprint: 74AF05DDD92027F5F0C3CDD50D85F29625A3F9FD
UserID: Yann Dirson <[email protected]>
UserID: Yann Dirson <[email protected]>

Fingerprint: 0579A97A2238EBF9BE61ED020F02A5E1163686A4
UserID: Francesco Paolo Lovergine <[email protected]>
UserID: Francesco Paolo Lovergine <[email protected]>
UserID: Francesco Paolo Lovergine <[email protected]>

Fingerprint: 5919FC3BDC30CE4135F1DC070F5E1ED4664196E2
UserID: Richard A. Hecker (NoWhereMan) <[email protected]>
UserID: Richard A. Hecker (NoWhereMan) <[email protected]>

Fingerprint: B62B5DA4A31446F014F8D66410252E653A91E527
UserID: maximilian attems <[email protected]>
UserID: maximilian attems <[email protected]>
UserID: maximilian attems <[email protected]>
UserID: maximilian attems <[email protected]>
UserID: maximilian attems <[email protected]>

Fingerprint: B6E62F3D12AC38495C0DA90510C293B6C37C4E36
UserID: Moritz Mühlenhoff <[email protected]>
UserID: Moritz Mühlenhoff <[email protected]>

Fingerprint: 0A463F5CE07D0979B5C5C90711192892EFD75934
UserID: Kenneth J. Pronovici <[email protected]>
UserID: Kenneth J. Pronovici <[email protected]>
UserID: Kenneth J. Pronovici <[email protected]>

Fingerprint: 64F429E36EA11CC2D966546F125B57475E190D18
UserID: Barak A. Pearlmutter <[email protected]>
UserID: Barak A. Pearlmutter <[email protected]>
UserID: Barak A. Pearlmutter <[email protected]>
UserID: Barak A. Pearlmutter <[email protected]>
UserID: Barak A. Pearlmutter <[email protected]>
UserID: Barak A. Pearlmutter <[email protected]>

Fingerprint: 0CA048866B0885360308456B15C0E9E382F72CBE
UserID: Ove Kåven <[email protected]>
UserID: Ove Kåven <[email protected]>

Fingerprint: DCE76C9A36785CE022EFCC271654965A49F7FC9B
UserID: Matthew Palmer <[email protected]>
UserID: Matthew Palmer <[email protected]>

Fingerprint: EC4784C5B0859A9A9FC5FCF017FBDCBFD9928FF4
UserID: Jochen Sprickerhof <[email protected]>
UserID: Jochen Sprickerhof <[email protected]>
UserID: Jochen Sprickerhof <[email protected]>
UserID: Jochen Sprickerhof <[email protected]>
UserID: Jochen Sprickerhof <[email protected]>
UserID: Jochen Sprickerhof <[email protected]>

Fingerprint: D516C42B1D0E3F854CAB97231909D4080C626242
UserID: Steve Kemp (Edinburgh, Scotland) <[email protected]>

Fingerprint: 8514067B1F1F5DF4E79DE0801A30765DF1F0D3ED
UserID: Sune Vuorela <[email protected]>
UserID: Sune Vuorela <[email protected]>
UserID: Sune Vuorela <[email protected]>

Fingerprint: 1AE77C660A265BFFDF225D551C570C890E4BD0AB
UserID: George Danchev (no comments) <[email protected]>
UserID: George Danchev <[email protected]>

Fingerprint: 52D5B1593D7FD9146A5A63071C7C41EDEBDDBB60
UserID: Brendan O'Dea <[email protected]>

Fingerprint: B1A51EB2779DD01743CC19BA1CF792111B5228B0
UserID: Alex Mestiashvili <[email protected]>
UserID: Alex Mestiashvili <[email protected]>
UserID: Alexandre Mestiashvili <[email protected]>
UserID: Alexandre Mestiashvili <[email protected]>
UserID: Alexandre Mestiashvili <[email protected]>

Fingerprint: 3133724D6207881579E95D621E1356881DD8D791
UserID: Osamu Aoki <[email protected]>

Fingerprint: BD111DBBB521B9C3082ACC9B1E2A2F0B19116AD8
UserID: Bastian Blank <[email protected]>
UserID: Bastian Blank <[email protected]>
UserID: Bastian Blank <[email protected]>
UserID: Bastian Blank <[email protected]>

Fingerprint: 6E3966C1E1D15DB973D05B491E45F8CA9DE23B16
UserID: Alexander Wirt (Debian) <[email protected]>
UserID: Alexander Wirt (formorer) <[email protected]>
UserID: Alexander Wirt <[email protected]>
UserID: Alexander Wirt <[email protected]>
UserID: Alexander Wirt <[email protected]>

Fingerprint: D0D085B169C3BFD9404858FA21FC29504B5230DB
UserID: Daniel Echeverry <[email protected]>
UserID: Daniel Echeverry <[email protected]>

Fingerprint: 7FEB617A87114E1BDE8C89C92713E679084651AF
UserID: Andrea Colangelo <[email protected]>
UserID: Andrea Colangelo <[email protected]>
UserID: Andrea Colangelo <[email protected]>
UserID: Andrea Colangelo <[email protected]>
UserID: Andrea Colangelo <[email protected]>
UserID: Andrea Colangelo <[email protected]>
UserID: Andrea Colangelo <[email protected]>
UserID: Andrea Colangelo <[email protected]>

Fingerprint: F4B472B56AC66F1A6ADF9F0E2770D9ADFD6C2A7E
UserID: Wilmer van der Gaast <[email protected]>
UserID: Wilmer van der Gaast <[email protected]>

Fingerprint: F3A12880BCF7F8047C39B29E292A35920034C733
UserID: Dennis L. Clark <[email protected]>
UserID: Dennis L. Clark <[email protected]>
UserID: Dennis L. Clark <[email protected]>

Fingerprint: BD1DDA696803C41A564A62072930100100003344
UserID: Gergely Risko <[email protected]>
UserID: Gergely Riskó <[email protected]>

Fingerprint: B11EE3273F6B2DEB528C93DA2BF8D9FE074BCDE4
UserID: Thomas Lange <[email protected]>
UserID: Thomas Lange <[email protected]>
UserID: Thomas Lange <[email protected]>

Fingerprint: 5F2A9FB82FA6C1E1077007072D191C8843B13F4D
UserID: Pino Toscano <[email protected]>
UserID: Pino Toscano <[email protected]>

Fingerprint: D5D568B2D34AB32A337944D22EC3F60DE71C0B9D
UserID: James Lu <[email protected]>
UserID: James Lu <[email protected]>
UserID: James Lu <[email protected]>
UserID: James Lu <[email protected]>
UserID: James Lu <[email protected]>
UserID: James Lu <[email protected]>
UserID: Lu, Jia Ming <[email protected]>

Fingerprint: 5E629EE5232197357B84CF4332247FBB40AD1FA6
UserID: Nobuhiro Iwamatsu <[email protected]>
UserID: Nobuhiro Iwamatsu <[email protected]>
UserID: Nobuhiro Iwamatsu <[email protected]>
UserID: Nobuhiro Iwamatsu <[email protected]>
UserID: Nobuhiro Iwamatsu <[email protected]>

Fingerprint: B638FD9E5E6B184FCF9E2363329465A24F1FC85D
UserID: Carsten Hey
UserID: Carsten Hey <[email protected]>
UserID: Carsten Hey <[email protected]>
UserID: Carsten Hey <[email protected]>

Fingerprint: E0D3FAAA6F50A5DA9D5B293833961588E1C21845
UserID: Thijs Kinkhorst <[email protected]>
UserID: Thijs Kinkhorst <[email protected]>
UserID: Thijs Kinkhorst <[email protected]>
UserID: Thijs Kinkhorst <[email protected]>
UserID: Thijs Kinkhorst <[email protected]>
UserID: Thijs Kinkhorst <[email protected]>

Fingerprint: AC8539A6E8F46702CA4A439B35A3939FFC78776D
UserID: Breno Leitao (IBM's email) <[email protected]>
UserID: Breno Leitao <[email protected]>
UserID: Breno Leitao <[email protected]>
UserID: Breno Leitao <[email protected]>

Fingerprint: 6DF18403037B3036A6F7172C387706A26998E5C4
UserID: Xavier Luthi <[email protected]>
UserID: Xavier Luthi <[email protected]>
UserID: Xavier Lüthi <[email protected]>
UserID: Xavier Lüthi <[email protected]>
UserID: Xavier Lüthi <[email protected]>
UserID: Xavier Lüthi <[email protected]>

Fingerprint: 2CAEAFA9987DB153FB4BCF1C3C2DD086F4523F9D
UserID: Tino Didriksen <[email protected]>
UserID: Tino Didriksen <[email protected]>
UserID: Tino Didriksen <[email protected]>
UserID: Tino Didriksen <[email protected]>
UserID: Tino Didriksen <[email protected]>
UserID: Tino Didriksen <[email protected]>

Fingerprint: DC1A298CE5C95ECE9A0882263D6903DFE1D316DC
UserID: Takuo Kitame <[email protected]>

Fingerprint: 22B3D97BE9E898C90FF6523B3E9B59AC6EC2D359
UserID: Nick Morrott <[email protected]>
UserID: Nick Morrott <[email protected]>

Fingerprint: 8944F03B2DFCE015306ACF363EABB1CB540A7E68
UserID: Ludovic Drolez <[email protected]>
UserID: Ludovic Drolez <[email protected]>
UserID: Ludovic Drolez <[email protected]>

Fingerprint: 4D1B7796C03E0831991BDD423F490DEB871EF9FA
UserID: Guus Sliepen <[email protected]>
UserID: Guus Sliepen <[email protected]>
UserID: Guus Sliepen <[email protected]>
UserID: Guus Sliepen <[email protected]>
UserID: Guus Sliepen <[email protected]>

Fingerprint: E3BA9117DCDF37B182B2F1DB4157ED054116CFEA
UserID: Thomas Schmidt <[email protected]>

Fingerprint: 8738A680B84B3031A630F2DB416F061063FEE659
UserID: Erinn Clark <[email protected]>
UserID: Erinn Clark <[email protected]>
UserID: Erinn Clark <[email protected]>
UserID: Erinn Clark <[email protected]>

Fingerprint: E11D1959BD866A8C37C7DE0D437FE24F9543CB69
UserID: Jean-Michel Kelbert <[email protected]>
UserID: Jean-Michel Kelbert <[email protected]>

Fingerprint: 7A5A4E80E40097BAF6EAD638449190F3235ABD3B
UserID: Brice Goglin <[email protected]>
UserID: Brice Goglin <[email protected]>
UserID: Brice Goglin <[email protected]>
UserID: Brice Goglin <[email protected]>
UserID: Brice Goglin <[email protected]>
UserID: Brice Goglin <[email protected]>

Fingerprint: 8B112EB026D4BCBAACB886A245DB6B56EC2D523D
UserID: Jaakko Niemi <[email protected]>
UserID: Jaakko Niemi <[email protected]>
UserID: Jaakko Niemi <[email protected]>

Fingerprint: 1CC31CA5AF3E7C4D40874FAA473C343BBEEE3333
UserID: Andrew McMillan (karora) <[email protected]>
UserID: Andrew McMillan <[email protected]>

Fingerprint: 1B470A1C043AB115A99638E048682904DEE27C7D
UserID: Ondřej Čertík <[email protected]>
UserID: Ondřej Čertík <[email protected]>

Fingerprint: 2FE2163F611C80BE2BF5EE6248D19F46BC99C9B7
UserID: Lee Garrett <[email protected]>
UserID: Lee Garrett <[email protected]>
UserID: Mark Lee Garrett <[email protected]>

Fingerprint: 140F202C78F643A57CE8B8F449C3BF8927553D2E
UserID: Guido Trotter <[email protected]>
UserID: Guido Trotter <[email protected]>

Fingerprint: 6CD068620DE13D1B938572334B0069CCF6527847
UserID: Bruno Kleinert <[email protected]>
UserID: Bruno Kleinert <[email protected]>
UserID: Bruno Kleinert <[email protected]>

Fingerprint: 5C48FE6157F49179597087C64C5A6BAB12D2A7AE
UserID: Christoph Berg <[email protected]>
UserID: Christoph Berg <[email protected]>
UserID: Christoph Berg <[email protected]>
UserID: Christoph Berg <[email protected]>

Fingerprint: 07CA87DDC4C2B06240B6B1745041F1891F44E090
UserID: A. Maitland Bottoms (aa4hs) <[email protected]>

Fingerprint: F75FBFCD771DEB5E9C86050550C3634D3A291CF9
UserID: Philipp Kern
UserID: Philipp Kern <[email protected]>
UserID: Philipp Kern <[email protected]>

Fingerprint: 50BC7CF939D20C272A6B065652B6BBD953968D1B
UserID: Dmitry Smirnov <[email protected]>
UserID: Dmitry Smirnov <[email protected]>
UserID: Dmitry Smirnov <[email protected]>
UserID: Dmitry Smirnov <[email protected]>
UserID: Dmitry Smirnov <[email protected]>
UserID: Dmitry Smirnov <[email protected]>

Fingerprint: F00C9F2F4F7EB714AFAD1A42538C0766F4BCB38E
UserID: Clint Byrum <[email protected]>
UserID: Clint Byrum <[email protected]>
UserID: Clint Byrum <[email protected]>
UserID: Clint Byrum <[email protected]>
UserID: Clint Byrum <[email protected]>
UserID: Clint Byrum <[email protected]>
UserID: Clint Byrum <[email protected]>
UserID: Clint Byrum <[email protected]>

Fingerprint: 6E7434F5897D43B17FCD57B753D5BC64B52378A2
UserID: Scott Talbert <[email protected]>

Fingerprint: 0EED77DC41D760FDE44035FF5556A34E04A3610B
UserID: Sascha Steinbiss <[email protected]>
UserID: Sascha Steinbiss <[email protected]>
UserID: Sascha Steinbiss <[email protected]>
UserID: Sascha Steinbiss <[email protected]>
UserID: Sascha Steinbiss <[email protected]>

Fingerprint: 12CCFE48BAD829BBD6BFFE3D566217F3C4395C9C
UserID: Piotr Roszatycki <[email protected]>
UserID: Piotr Roszatycki <[email protected]>

Fingerprint: 930BB50F68C747D2A0E70FA4566E861304468DEC
UserID: Al Nikolov <[email protected]>
UserID: Al Nikolov <[email protected]>
UserID: Al Nikolov <[email protected]>

Fingerprint: A7400F5A48FB42B8CEE8638B5759F35001AA4A64
UserID: Steve Langasek <[email protected]>
UserID: Steve Langasek <[email protected]>
UserID: Steve Langasek <[email protected]>
UserID: Steve Langasek <[email protected]>

Fingerprint: 3B21B8E68AE5C16F87F5322D5792783B206FEE30
UserID: Sophie Brun <[email protected]>
UserID: Sophie Brun <[email protected]>
UserID: Sophie Brun <[email protected]>

Fingerprint: B8FAC2E250475B8CE940A91957930DAB0B86B067
UserID: Joost E. van Baal (Nederland, 1970)
UserID: Joost van Baal <[email protected]>
UserID: Joost van Baal <[email protected]>
UserID: Joost van Baal <[email protected]>
UserID: Joost van Baal <[email protected]>
UserID: Joost van Baal <[email protected]>
UserID: Joost van Baal <[email protected]>
UserID: Joost van Baal-Ilić

Fingerprint: 59E895A48D09D6C8EBB94CE857E7C6324F81391D
UserID: Sergei Golovan <[email protected]>
UserID: Sergei Golovan <[email protected]>
UserID: Sergei Golovan <[email protected]>

Fingerprint: B73823B302F8A2426FCA1BBE590AE197EF123736
UserID: Juliane Friederike Holzt <[email protected]>
UserID: Juliane Holzt <[email protected]>

Fingerprint: 17EF07E6F59E9F3E16E0C0A259EC43D65246508B
UserID: Dale E. Martin <[email protected]>
UserID: Dale E. Martin <[email protected]>

Fingerprint: 1C9A2574B1A48D8AC243CAE55C29137271246E4A
UserID: Muammar El Khatib (Debian) <[email protected]>
UserID: Muammar El Khatib <[email protected]>

Fingerprint: 6F1D26E46B6612334228B04A5EA2BDB6883CCDE2
UserID: Chen Baozi <[email protected]>
UserID: Chen Baozi <[email protected]>
UserID: Chen Baozi <[email protected]>

Fingerprint: 638BC75EC1E5C589067E35DE62645EB35F686A8A
UserID: Mo Zhou <[email protected]>
UserID: Mo Zhou <[email protected]>
UserID: Mo Zhou <[email protected]>
UserID: Mo Zhou <[email protected]>
UserID: Zhou Mo (Passport) <[email protected]>
UserID: Zhou Mo (master 4096 gmail key) <[email protected]>

Fingerprint: 3006C9FBBFC9CAB82FA38A2A63CE20BAC49C4148
UserID: Tim Cutts (Debian Development) <[email protected]>
UserID: Tim Cutts <[email protected]>
UserID: Tim Cutts <[email protected]>

Fingerprint: D20D5E7E7BDA7633BEA14A9F67708B14E1C142B1
UserID: Brian White <[email protected]>
UserID: Brian White <[email protected]>

Fingerprint: 3DF1A4DFC732468838BCF121686930DD58C338B3
UserID: Marcin Kulisz (kuLa) <[email protected]>
UserID: Marcin Kulisz <[email protected]>
UserID: Marcin Kulisz <[email protected]>
UserID: Marcin Kulisz <[email protected]>

Fingerprint: DD9861AB23DC3333892E07A968E713981D1515F8
UserID: Arturo Borrero Gonzalez (Centro Informatico Cientifico de Andalucia - CICA) <[email protected]>
UserID: Arturo Borrero Gonzalez <[email protected]>
UserID: Arturo Borrero Gonzalez <[email protected]>
UserID: Arturo Borrero Gonzalez <[email protected]>
UserID: Arturo Borrero Gonzalez <[email protected]>
UserID: Arturo Borrero Gonzalez <[email protected]>

Fingerprint: D8812F4065320B8DCA3CEF18694CADEF51C7B5B6
UserID: Michael Fladischer (Medical University of Graz) <[email protected]>
UserID: Michael Fladischer <[email protected]>
UserID: Michael Fladischer <[email protected]>
UserID: Michael Fladischer <[email protected]>
UserID: Michael Fladischer <[email protected]>
UserID: Michael Fladischer <[email protected]>

Fingerprint: 648DD98F4BC4829017CB0E3469740E5CB35FEC3C
UserID: Eduard Bloch <[email protected]>
UserID: Eduard Bloch <[email protected]>

Fingerprint: 2FAFEBB52F5F5DCE5570D2E66C6ACD6417B3ACB1
UserID: Roger SHIMIZU <[email protected]>
UserID: Roger Shimizu <[email protected]>
UserID: Roger Shimizu <[email protected]>
UserID: Roger Shimizu <[email protected]>

Fingerprint: 20A741B470D74B2077D029E86C7BFF9E99746B65
UserID: Pablo Lorenzzoni (Spectra) <[email protected]>
UserID: Pablo Lorenzzoni (Spectra) <[email protected]>

Fingerprint: 4CB7FE1E280ECC90F29A597E6E608B637D8967E9
UserID: Miguel Landaeta (Debian) <[email protected]>
UserID: Miguel Landaeta (LDC) <[email protected]>
UserID: Miguel Landaeta (Open English) <[email protected]>
UserID: Miguel Landaeta (Restorando) <[email protected]>
UserID: Miguel Landaeta <[email protected]>
UserID: Miguel Landaeta <[email protected]>

Fingerprint: BCA6F0EF11B23F924BA392296FE413326DC4B226
UserID: John H. Robinson, IV <[email protected]>
UserID: John H. Robinson, IV <[email protected]>
UserID: John H. Robinson, IV <[email protected]>
UserID: John H. Robinson, IV <[email protected]>

Fingerprint: BAFC6C85F7CB143FEEB6FB157115AFD07710DCF7
UserID: Ole Streicher <[email protected]>
UserID: Ole Streicher <[email protected]>

Fingerprint: ABE195E150A8DBE7809D3F427127E5ABEEF946C8
UserID: Mirco Bauer <[email protected]>
UserID: Mirco Bauer <[email protected]>
UserID: Mirco Bauer <[email protected]>
UserID: Mirco Bauer <[email protected]>
UserID: Mirco Bauer <[email protected]>
UserID: Mirco Bauer <[email protected]>

Fingerprint: E0FD6DAE7C51262FDAE6A28B7174A18FAAA7A078
UserID: Asias He <[email protected]>
UserID: Asias He <[email protected]>
UserID: Asias He <[email protected]>

Fingerprint: 02054829E12D0F2A8E648E62745C4766D4CACDFF
UserID: Ralf Treinen <[email protected]>

Fingerprint: AE731055442A1D96CF4D4C7875B710635C213A7E
UserID: Hilko Bengen <[email protected]>

Fingerprint: 2AB8EB163CA562E182A13AAE7731FCCC63E4E277
UserID: Roberto C. Sanchez <[email protected]>
UserID: Roberto C. Sanchez <[email protected]>
UserID: Roberto C. Sanchez <[email protected]>

Fingerprint: BE3D8AF066B6EC8079667FD777C1D22D53E15F02
UserID: Joachim Bauch <[email protected]>
UserID: Joachim Bauch <[email protected]>
UserID: Joachim Bauch <[email protected]>

Fingerprint: F5E11B9FFE911146F41D953D78A1B4DFE8F9C57E
UserID: Ludovic Rousseau <[email protected]>
UserID: Ludovic Rousseau <[email protected]>

Fingerprint: C6045C813887B77C2DFF97A57C56ACFE947897D8
UserID: Anibal Monsalve Salazar <[email protected]>
UserID: Anibal Monsalve Salazar <[email protected]>

Fingerprint: EB3345F56441B8B81A7798767DFA41AD961985D7
UserID: Gennaro Oliva <[email protected]>
UserID: Gennaro Oliva <[email protected]>
UserID: Gennaro Oliva <[email protected]>
UserID: Gennaro Oliva <[email protected]>

Fingerprint: 3453B5A2F40603D7FF9FFAF07E0A399DB24B3B15
UserID: Matthew Garrett <[email protected]>
UserID: Matthew Garrett <[email protected]>
UserID: Matthew Garrett <[email protected]>

Fingerprint: B60DB5994D39BEC4D1A95CCF7E6528DA752F1BE1
UserID: Sylvestre Ledru <[email protected]>
UserID: Sylvestre Ledru <[email protected]>
UserID: Sylvestre Ledru <[email protected]>
UserID: Sylvestre Ledru <[email protected]>
UserID: Sylvestre Ledru <[email protected]>
UserID: Sylvestre Ledru <[email protected]>
UserID: Sylvestre Ledru <[email protected]>
UserID: Sylvestre Ledru <[email protected]>
UserID: Sylvestre Ledru <[email protected]>

Fingerprint: 91EECA611F18DA32AFA40E2E84CCF98060F105FE
UserID: Klee Dienes <[email protected]>
UserID: Klee Dienes <[email protected]>
UserID: Klee Dienes <[email protected]>
UserID: Klee Dienes <[email protected]>
UserID: Klee Dienes <[email protected]>

Fingerprint: 7E43E9ACBF727AB3CF0885338716CE4614A452D8
UserID: Sebastien Badia <[email protected]>
UserID: Sebastien Badia <[email protected]>
UserID: Sebastien Badia <[email protected]>
UserID: Sebastien Badia <[email protected]>
UserID: Sebastien Badia <[email protected]>
UserID: Sebastien Badia <[email protected]>

Fingerprint: 6583B3EBB874F4544D5D2B23873DEA309D13807F
UserID: Chrysostomos Nanakos <[email protected]>
UserID: Nanakos Chrysostomos (Chris) <[email protected]>

Fingerprint: 1998FD821B7124F525B25133888220B87E798989
UserID: Ari Pollak <[email protected]>
UserID: Ari Pollak <[email protected]>
UserID: Ari Pollak <[email protected]>

Fingerprint: 1DF6A19FCA53F97353F3F35D8A0A48874687AF4F
UserID: Toni Mueller (code signing) <[email protected]>
UserID: Toni Mueller <[email protected]>
UserID: Toni Mueller <[email protected]>
UserID: Toni Mueller <[email protected]>
UserID: Toni Mueller <[email protected]>

Fingerprint: C2C96B10011FE009E6D1DF828A75D10998012C7E
UserID: Jay Berkenbilt <[email protected]>
UserID: Jay Berkenbilt <[email protected]>

Fingerprint: 1C977AFDCD9B00F2BC509A088C09994F6E48A047
UserID: Ean Schuessler <[email protected]>
UserID: Ean Schuessler <[email protected]>
UserID: Ean Schuessler <[email protected]>

Fingerprint: 9FDFBD2937CEC8A249DD4D9C8CBE219C74576D81
UserID: Willi Mann <[email protected]>
UserID: Willi Mann <[email protected]>

Fingerprint: 71EDACFC68010DD91AD19B868D1F969A08EEA756
UserID: Dmitry E. Oboukhov <[email protected]>
UserID: Dmitry E. Oboukhov <[email protected]>
UserID: Dmitry E. Oboukhov <[email protected]>
UserID: Dmitry E. Oboukhov <[email protected]>
UserID: Dmitry E. Oboukhov <[email protected]>
UserID: Dmitry E. Oboukhov <[email protected]>

Fingerprint: 8795AF2E4A1A4EFBA068A4498E889544D985000D
UserID: Bastian Venthur <[email protected]>
UserID: Bastian Venthur <[email protected]>
UserID: Bastian Venthur <[email protected]>
UserID: Bastian Venthur <[email protected]>
UserID: Bastian Venthur <[email protected]>

Fingerprint: 42028EA404A2E9D80AC453148F0E7C2B4522E387
UserID: Bill Allombert <[email protected]>
UserID: Bill Allombert <[email protected]>
UserID: Bill Allombert <[email protected]>

Fingerprint: 59472423E07FE30FD47A8BB7925252C459797A1D
UserID: Hanno 'Rince' Wagner (Debian-Key) <[email protected]>
UserID: Hanno 'Rince' Wagner (debian-Key) <[email protected]>

Fingerprint: 2A62FCF3BBE867727440369C9258A798513F86CD
UserID: Brian Thomason <[email protected]>
UserID: Brian Thomason <[email protected]>
UserID: Brian Thomason <[email protected]>

Fingerprint: 795D0851095CAACA16CA79259AFB7B8C9A5F5BBC
UserID: Heiko Stuebner <[email protected]>
UserID: Heiko Stuebner <[email protected]>
UserID: Heiko Stuebner <[email protected]>
UserID: Heiko Stuebner <[email protected]>
UserID: Heiko Stübner <[email protected]>

Fingerprint: 91B46ECD90312D7C86F9469A9BD2D6409A0C52FA
UserID: Laszlo Kajan <[email protected]>
UserID: Laszlo Kajan <[email protected]>
UserID: Laszlo Kajan <[email protected]>

Fingerprint: A8DF13269E5D9A38E57CFAC29D20F6503E338888
UserID: Mike Dotty <[email protected]>
UserID: Mike Dotty <[email protected]>
UserID: Mikhail Gusarov <[email protected]>
UserID: Mikhail Gusarov <[email protected]>
UserID: Mikhail Gusarov <[email protected]>
UserID: Mikhail Gusarov <[email protected]>

Fingerprint: BAE0340127D536AD2CB12FE09EC002FE1C9CA517
UserID: Michael C. Schultheiss (GSWoT:US74) <[email protected]>
UserID: Michael C. Schultheiss (GSWoT:US74) <[email protected]>
UserID: Michael C. Schultheiss <[email protected]>
UserID: Michael C. Schultheiss <[email protected]>
UserID: Michael C. Schultheiss <[email protected]>

[continued in next message]

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

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

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from home https://framapiaf.org/@charles_plessy
- You do not have my permission to use this email to train an AI -

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

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

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

iHUEABYKAB0WIQRB1rjSpCJd8a7h6mNgNUJZCjx8YgUCZ9u/rwAKCRBgNUJZCjx8 YtP7AQCBoeIubWTunxFlFpilJFMZgbmUfdkfIK2raYNXJ2f0iAEArnOSt1u1wbf9 stepjeFciDwy/xu+c0GZpdqy4r6Jawc=
=5LjB
-----END PGP SIGNATURE-----

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

Hi!

On Thu, 2025-03-20 at 10:55:16 +0900, Charles Plessy wrote:

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

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

On Thu, Mar 20, 2025 at 01:14:57PM +0100, Guillem Jover wrote:

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.

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

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmfcEM0ACgkQCRq4Vgaa qhwyZRAAh4j3cYP3btHlqa77joPiXT0sJJUCCI1KkEQgBrgSnRQxeXQwwn/830RG qaZNWhSMWWGpTiq0N8APsm6Dfn04J/iq/4+8nWPKMGAQFqjo2UIJ2+ZnMb6YrtAE RH5hdWB4TSwao/XGzzloKECqZzn7pOnI6BBRGkqtO3Z/GHqs8Rp/DfYLIMAvDp6c toGhCE0hUWfMgxHHdgk6Ey4zbhkpO+/FOLmVaUZ6k8y5ncVl4wxNMu3AEktHi9/J KtPObR07/jbG5hd8TpshY4mG3NWYVBsvfbdrdTyBxWHuzSu/WRSEw1diy3HsBDCu lK1RTCpnFaIbjdCX+qm4UgG8vyjh6pa7sxPLrSdisgFA5+a3gRp36ik3FHybLNUd
bMFwwa8TYv

Guillem Jover wrote...

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

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

iQIzBAABCgAdFiEEWXMI+726A12MfJXdxCxY61kUkv0FAmfcgdAACgkQxCxY61kU kv0ndRAA5hwz0TL69JJgspU+hmlMxs9vVJ02eOsdReYEnBHUNyjo21MWROWybna3 mT8UAQEvU5q/SMbfpH2MnPwvEeGlOtg2yG+gTxR2/wfEkZgK2UgZRC4gYqSXzkyG UC7PO6E/T4VAfwyoRkiLEkiHaKDshIAJ/N8QzesRw0ssOQGDKwpbyTAAC80bEQO6 y3Zjn5FhouS3SryCEPTukrcC+MYEdzOS0jNAev4HJzBMfsvSN5S4rFsx0PushAqJ WGgTM26ZBMSTTV51YUUX/ZnTkp9E9dvJx9Qnzuz2CrIF98ufkhSnl9ZqNZ828eNg vIA4IT/B1gugxEjWAtDX26aZo6AkfHC2u4k/yW/kD9bReIdd/KDi0KxNQkupuCDw /nBESZp33ue8QVizeX6pr6ZjPAl4kzGGb38NP5Z1yqJQqgx4L/AcdRCMMNKwA5Ki sdST5K+cxwJGzJv+I3WDT35lmU1Gbep7YVJXVGiYgmttdg6CPjJX8jplSigbD9/H lwS9mrcgEkK/wmbKMm28dQTYgt9hfCcgdzKjwEHx79veHJ/Ho/YuTQ5Rm7zYWqbB D/ejeRTBY9fTb9pLKaXfxOvNC2waYzPs0bYtOYgVOI0woMX/0JlWP7KIiEgDAO+C ACp509vJEhmS8z4141HyPvGOepM3aq2yySy439U1pkdOie8rhC0=
=QQMD
-----END PGP SIGNATURE-----

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

Hi!

On Thu, 2025-03-20 at 22:00:04 +0100, Christoph Biedl wrote:

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!

So those people you listed:

* 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.

* 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.

* 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) <[email protected]>"
$ 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.

* 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.

* 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.

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

* 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

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

[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.]

On Fri, Mar 21, 2025 at 01:11:20AM +0100, Guillem Jover wrote:

On Thu, 2025-03-20 at 22:00:04 +0100, Christoph Biedl wrote:

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!

So those people you listed:

* 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.

* 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.

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.

--
] https://www.earth.li/~noodles/ [] "f u cn rd ths, u cn gt a gd jb n [
] PGP/GPG Key @ the.earth.li [] cmptr prgrmmng." -- Simon Cozens, [
] via keyserver, web or email. [] ox.os.linux [
] RSA: 4096/0x94FA372B2DA8B985 [] [

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

Guillem Jover wrote...

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

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

iQIzBAABCgAdFiEEWXMI+726A12MfJXdxCxY61kUkv0FAmfejuQACgkQxCxY61kU kv10hA//dw2/Pn03EZQGkk6XXRP1fNZVAp0sE66xdYqJkO+rFlgz6iStgyYxOmsY 9vXdz+WM1d26tGgMlWoJnX5MPwG1p3nVKRShRl5UiIScI7JJ3SswgZxyHFZ8+swJ 52XyA0BlLnNvcGuY1qzmvaTYf5lntt/CDaY7aEBgQZVUm/nptqSn9kKvchOKPQ+C l2uVWAkI1WHh6BI9iNzY6mJNMprfIXzd1KOcx4hExaeSA5akMNu7Dou2OxfC3WH6 GfoQaojfdshs43ToIPoTO0MxSZKcOX6mimfYEeWDlSCg1I5waEJ5fa/WIn1aoOkB 5/lHvMof725B9U/3ChIrzyge6tF5+3ED7jpCyhIiDAKUSclkgkGoT5UR0tStWBdt 6Ah6H2144zaFP9BrGsOmgfYfH5GVb0FGjCVsxcltDfU08To4xkIlyuNt+97oAi25 arzD39Hha0khr5dGFMcmMX8hWCucjCjZGkxhdtRg8BppOjLhKxpUEH5cCBrgaPgc nfzIYE3phNEa4sxXxkBE+1huUzp6xj/Bm2GiBd579JmWESJ3bG+2K+Wq/amnKdzX Vh1hyxUzuLZq6xAf0mi2xIfkaTUqL9Zb9hFIDesNIi3femcPy9ryLJTbUoRUPNsI /cpKKCxs4fqCM8a/DZDKFrxwtnMHiCRtkB89Logv1L0acYq044M=
=e2Ml
-----END PGP SIGNATURE-----

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

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 <[email protected]>
UserID: Robert Edmonds <[email protected]>
UserID: Robert Edmonds <[email protected]>

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

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