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) <josueortega@debian.org.gt>
UserID: Josue Ortega (debian gpg) <josuerortega@gmail.com>
UserID: Josue Ortega <josue@debian.org>
UserID: Josue Ortega <josueortega@debian.org.gt>
UserID: Josue Ortega <josueortega@protonmail.ch>
UserID: Josue Ortega <josueortega@riseup.net>

Fingerprint: DF3D96EEB3827820F302665C01817AB0AAF6CDAE
UserID: Robert Edmonds <edmonds@debian.org>
UserID: Robert Edmonds <edmonds@fsi.io>
UserID: Robert Edmonds <edmonds@mycre.ws>

Fingerprint: 45877F1F6F591AB1F366BC3A02541A371530B71F
UserID: Gert Wollny (DM key) <gw.fossdev@gmail.com>
UserID: Gert Wollny <gert.wollny@collabora.com>
UserID: Gert Wollny <gewo@debian.org>

Fingerprint: DD34BB88EFB7DE735C77597C0270A2758CD736E2
UserID: Carl Chenet (MyTux) <carl.chenet@mytux.fr>
UserID: Carl Chenet <chaica@brebisproject.org>
UserID: Carl Chenet <chaica@debian.org>
UserID: Carl Chenet <chaica@ohmytux.com>

Fingerprint: 812EEFD8A3FBA4ACE4DF114B04C53BD7FE030551
UserID: Julien Puydt (Debian) <julien.puydt@laposte.net>
UserID: Julien Puydt <jpuydt@debian.org>

Fingerprint: 2255310AD1A248A07B597638065FE53932DC551D
UserID: Geoffroy Berret <geoffroy.berret@azylum.org>
UserID: Geoffroy Youri Berret <efrim@azylum.org>
UserID: Geoffroy Youri Berret <kaliko@debian.org>
UserID: Jack Kaliko (dev id) <kaliko@azylum.org>

Fingerprint: 7F4BC7CC3CA06F97336BBFEB0668CC1486C2D7B5
UserID: Sebastian Dröge <sebastian@centricular.com>
UserID: Sebastian Dröge <slomo@circular-chaos.org>
UserID: Sebastian Dröge <slomo@coaxion.net>
UserID: Sebastian Dröge <slomo@debian.org>

Fingerprint: E037CB2A1A0061B943363C8B0907409606AAAAAA
UserID: Jon Dowland <jmtd@debian.org>
UserID: Jon Dowland <jon.dowland@ncl.ac.uk>
UserID: Jon Dowland <jon@alcopop.org>
UserID: Jonathan Dowland <jmtd@debian.org>
UserID: Jonathan Dowland <jon+github@alcopop.org>
UserID: Jonathan Dowland <jon@dow.land>
UserID: Jonathan Dowland <jon@dowland.me>

Fingerprint: FAE1E5B64652BE798E278CC20BC47DC64D135306
UserID: Andreas Henriksson <ah@debian.org>
UserID: Andreas Henriksson <andreas@fatal.se>

Fingerprint: 5340D001360CA656E3497EB70C48EA2A7A8FFD7B
UserID: Peter Michael Green <plugwash@debian.org>
UserID: Peter Michael Green <plugwash@p10link.net>

Fingerprint: 74AF05DDD92027F5F0C3CDD50D85F29625A3F9FD
UserID: Yann Dirson <dirson@debian.org>
UserID: Yann Dirson <ydirson@free.fr>

Fingerprint: 0579A97A2238EBF9BE61ED020F02A5E1163686A4
UserID: Francesco Paolo Lovergine <francesco@lovergine.com>
UserID: Francesco Paolo Lovergine <frankie@debian.org>
UserID: Francesco Paolo Lovergine <frankie@linux.com>

Fingerprint: 5919FC3BDC30CE4135F1DC070F5E1ED4664196E2
UserID: Richard A. Hecker (NoWhereMan) <hecker@debian.org>
UserID: Richard A. Hecker (NoWhereMan) <hecker@hecker.debian.net>

Fingerprint: B62B5DA4A31446F014F8D66410252E653A91E527
UserID: maximilian attems <attems@fias.uni-frankfurt.de>
UserID: maximilian attems <maks@debian.org>
UserID: maximilian attems <maks@kernel.org>
UserID: maximilian attems <maks@stro.at>
UserID: maximilian attems <mattems@hep.itp.tuwien.ac.at>

Fingerprint: B6E62F3D12AC38495C0DA90510C293B6C37C4E36
UserID: Moritz Mühlenhoff <jmm@debian.org>
UserID: Moritz Mühlenhoff <jmm@inutil.org>

Fingerprint: 0A463F5CE07D0979B5C5C90711192892EFD75934
UserID: Kenneth J. Pronovici <kpronovici@cedar-solutions.com>
UserID: Kenneth J. Pronovici <pronovic@debian.org>
UserID: Kenneth J. Pronovici <pronovic@ieee.org>

Fingerprint: 64F429E36EA11CC2D966546F125B57475E190D18
UserID: Barak A. Pearlmutter <bap@debian.org>
UserID: Barak A. Pearlmutter <barak.pearlmutter@alumni.cmu.edu>
UserID: Barak A. Pearlmutter <barak.pearlmutter@gmail.com>
UserID: Barak A. Pearlmutter <barak.pearlmutter@nuim.ie>
UserID: Barak A. Pearlmutter <barak@cs.nuim.ie>
UserID: Barak A. Pearlmutter <barak@pearlmutter.net>

Fingerprint: 0CA048866B0885360308456B15C0E9E382F72CBE
UserID: Ove Kåven <ovek@arcticnet.no>
UserID: Ove Kåven <post@ovekaaven.com>

Fingerprint: DCE76C9A36785CE022EFCC271654965A49F7FC9B
UserID: Matthew Palmer <mpalmer@debian.org>
UserID: Matthew Palmer <mpalmer@hezmatt.org>

Fingerprint: EC4784C5B0859A9A9FC5FCF017FBDCBFD9928FF4
UserID: Jochen Sprickerhof <debian@jochen.sprickerhof.de>
UserID: Jochen Sprickerhof <git@jochen.sprickerhof.de>
UserID: Jochen Sprickerhof <jochen@sprickerhof.de>
UserID: Jochen Sprickerhof <jspricke@debian.org>
UserID: Jochen Sprickerhof <jspricke@uni-osnabrueck.de>
UserID: Jochen Sprickerhof <launchpad@jochen.sprickerhof.de>

Fingerprint: D516C42B1D0E3F854CAB97231909D4080C626242
UserID: Steve Kemp (Edinburgh, Scotland) <steve@steve.org.uk>

Fingerprint: 8514067B1F1F5DF4E79DE0801A30765DF1F0D3ED
UserID: Sune Vuorela <debian@pusling.com>
UserID: Sune Vuorela <sune@debian.org>
UserID: Sune Vuorela <sune@vuorela.dk>

Fingerprint: 1AE77C660A265BFFDF225D551C570C890E4BD0AB
UserID: George Danchev (no comments) <danchev@spnet.net>
UserID: George Danchev <danchev@spnet.net>

Fingerprint: 52D5B1593D7FD9146A5A63071C7C41EDEBDDBB60
UserID: Brendan O'Dea <bod@debian.org>

Fingerprint: B1A51EB2779DD01743CC19BA1CF792111B5228B0
UserID: Alex Mestiashvili <amestia@rsh2.donotuse.de>
UserID: Alex Mestiashvili <mailatgoogl@gmail.com>
UserID: Alexandre Mestiashvili <alex@biotec.tu-dresden.de>
UserID: Alexandre Mestiashvili <mailatgoogl@gmail.com>
UserID: Alexandre Mestiashvili <mestia@debian.org>

Fingerprint: 3133724D6207881579E95D621E1356881DD8D791
UserID: Osamu Aoki <osamu@debian.org>

Fingerprint: BD111DBBB521B9C3082ACC9B1E2A2F0B19116AD8
UserID: Bastian Blank <bastian.blank@credativ.de>
UserID: Bastian Blank <bastian@waldi.eu.org>
UserID: Bastian Blank <bblank@thinkmo.de>
UserID: Bastian Blank <waldi@debian.org>

Fingerprint: 6E3966C1E1D15DB973D05B491E45F8CA9DE23B16
UserID: Alexander Wirt (Debian) <formorer@debian.org>
UserID: Alexander Wirt (formorer) <formorer@formorer.de>
UserID: Alexander Wirt <alexander.wirt@credativ.de>
UserID: Alexander Wirt <awirt@hs42.com>
UserID: Alexander Wirt <formorer@grml.org>

Fingerprint: D0D085B169C3BFD9404858FA21FC29504B5230DB
UserID: Daniel Echeverry <epsilon77@gmail.com>
UserID: Daniel Echeverry <epsilon@debian.org>

Fingerprint: 7FEB617A87114E1BDE8C89C92713E679084651AF
UserID: Andrea Colangelo <andrea.colangelo@beeseek.org>
UserID: Andrea Colangelo <andrea.colangelo@gmail.com>
UserID: Andrea Colangelo <andrea.colangelo@rapsodoo.com>
UserID: Andrea Colangelo <andrea@colangelo.eu>
UserID: Andrea Colangelo <andreacolangelo@openforce.it>
UserID: Andrea Colangelo <warp10@debian.org>
UserID: Andrea Colangelo <warp10@libero.it>
UserID: Andrea Colangelo <warp10@ubuntu.com>

Fingerprint: F4B472B56AC66F1A6ADF9F0E2770D9ADFD6C2A7E
UserID: Wilmer van der Gaast <lintux@debian.org>
UserID: Wilmer van der Gaast <wilmer@gaast.net>

Fingerprint: F3A12880BCF7F8047C39B29E292A35920034C733
UserID: Dennis L. Clark <Dennis.Clark@bullamakanka.net>
UserID: Dennis L. Clark <dbugger@debian.org>
UserID: Dennis L. Clark <dlclark1@uncc.edu>

Fingerprint: BD1DDA696803C41A564A62072930100100003344
UserID: Gergely Risko <risko@debian.org>
UserID: Gergely Riskó <gergely@risko.hu>

Fingerprint: B11EE3273F6B2DEB528C93DA2BF8D9FE074BCDE4
UserID: Thomas Lange <lange@cs.uni-koeln.de>
UserID: Thomas Lange <lange@debian.org>
UserID: Thomas Lange <lange@informatik.uni-koeln.de>

Fingerprint: 5F2A9FB82FA6C1E1077007072D191C8843B13F4D
UserID: Pino Toscano <pino@debian.org>
UserID: Pino Toscano <toscano.pino@tiscali.it>

Fingerprint: D5D568B2D34AB32A337944D22EC3F60DE71C0B9D
UserID: James Lu <GLolol@overdrivenetworks.com>
UserID: James Lu <bitflip3@gmail.com>
UserID: James Lu <glolol1@hotmail.com>
UserID: James Lu <hello@jlu5.com>
UserID: James Lu <james@overdrivenetworks.com>
UserID: James Lu <jlu@debian.org>
UserID: Lu, Jia Ming <jlu@debian.org>

Fingerprint: 5E629EE5232197357B84CF4332247FBB40AD1FA6
UserID: Nobuhiro Iwamatsu <hemamu@t-base.ne.jp>
UserID: Nobuhiro Iwamatsu <iwamatsu@debian.or.jp>
UserID: Nobuhiro Iwamatsu <iwamatsu@debian.org>
UserID: Nobuhiro Iwamatsu <iwamatsu@kernel.org>
UserID: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>

Fingerprint: B638FD9E5E6B184FCF9E2363329465A24F1FC85D
UserID: Carsten Hey
UserID: Carsten Hey <c.hey@web.de>
UserID: Carsten Hey <carsten@debian.org>
UserID: Carsten Hey <mail@carsten-hey.de>

Fingerprint: E0D3FAAA6F50A5DA9D5B293833961588E1C21845
UserID: Thijs Kinkhorst <kink@squirrelmail.org>
UserID: Thijs Kinkhorst <thijs.kinkhorst@surf.nl>
UserID: Thijs Kinkhorst <thijs.kinkhorst@surfnet.nl>
UserID: Thijs Kinkhorst <thijs@debian.org>
UserID: Thijs Kinkhorst <thijs@kinkhorst.com>
UserID: Thijs Kinkhorst <thijs@uvt.nl>

Fingerprint: AC8539A6E8F46702CA4A439B35A3939FFC78776D
UserID: Breno Leitao (IBM's email) <brenohl@br.ibm.com>
UserID: Breno Leitao <breno.leitao@gmail.com>
UserID: Breno Leitao <leitao@FreeBSD.org>
UserID: Breno Leitao <leitao@debian.org>

Fingerprint: 6DF18403037B3036A6F7172C387706A26998E5C4
UserID: Xavier Luthi <xavier@luthi.eu>
UserID: Xavier Luthi <xluthi@debian.org>
UserID: Xavier Lüthi <xavier@caroxav.be>
UserID: Xavier Lüthi <xavier@luthi.eu>
UserID: Xavier Lüthi <xluthi@debian.org>
UserID: Xavier Lüthi <xluthi@gmail.com>

Fingerprint: 2CAEAFA9987DB153FB4BCF1C3C2DD086F4523F9D
UserID: Tino Didriksen <consult@tinodidriksen.com>
UserID: Tino Didriksen <mail@tinodidriksen.com>
UserID: Tino Didriksen <tino.didriksen@gmail.com>
UserID: Tino Didriksen <tino@didriksen.cc>
UserID: Tino Didriksen <tino@language.sdu.dk>
UserID: Tino Didriksen <tinod@sdu.dk>

Fingerprint: DC1A298CE5C95ECE9A0882263D6903DFE1D316DC
UserID: Takuo Kitame <kitame@debian.org>

Fingerprint: 22B3D97BE9E898C90FF6523B3E9B59AC6EC2D359
UserID: Nick Morrott <knowledgejunkie@gmail.com>
UserID: Nick Morrott <nickm@debian.org>

Fingerprint: 8944F03B2DFCE015306ACF363EABB1CB540A7E68
UserID: Ludovic Drolez <ldrolez@aopensource.com>
UserID: Ludovic Drolez <ldrolez@debian.org>
UserID: Ludovic Drolez <ldrolez@free.fr>

Fingerprint: 4D1B7796C03E0831991BDD423F490DEB871EF9FA
UserID: Guus Sliepen <Guus.Sliepen@astro.su.se>
UserID: Guus Sliepen <guus@debian.org>
UserID: Guus Sliepen <guus@meshlink.io>
UserID: Guus Sliepen <guus@sliepen.org>
UserID: Guus Sliepen <guus@tinc-vpn.org>

Fingerprint: E3BA9117DCDF37B182B2F1DB4157ED054116CFEA
UserID: Thomas Schmidt <tschmidt@debian.org>

Fingerprint: 8738A680B84B3031A630F2DB416F061063FEE659
UserID: Erinn Clark <erinn@debian.org>
UserID: Erinn Clark <erinn@double-helix.org>
UserID: Erinn Clark <erinn@torproject.org>
UserID: Erinn Clark <erinnc@bellsouth.net>

Fingerprint: E11D1959BD866A8C37C7DE0D437FE24F9543CB69
UserID: Jean-Michel Kelbert <jeanmichel.kelbert@gmail.com>
UserID: Jean-Michel Kelbert <kelbert@debian.org>

Fingerprint: 7A5A4E80E40097BAF6EAD638449190F3235ABD3B
UserID: Brice Goglin <Brice.Goglin@ens-lyon.org>
UserID: Brice Goglin <Brice.Goglin@free.fr>
UserID: Brice Goglin <Brice.Goglin@inria.fr>
UserID: Brice Goglin <Brice.Goglin@labri.fr>
UserID: Brice Goglin <bgoglin@debian.org>
UserID: Brice Goglin <bgoglin@free.fr>

Fingerprint: 8B112EB026D4BCBAACB886A245DB6B56EC2D523D
UserID: Jaakko Niemi <jaakko.niemi@iki.fi>
UserID: Jaakko Niemi <liiwi@debian.org>
UserID: Jaakko Niemi <liiwi@iki.fi>

Fingerprint: 1CC31CA5AF3E7C4D40874FAA473C343BBEEE3333
UserID: Andrew McMillan (karora) <awm@debian.org>
UserID: Andrew McMillan <andrew@mcmillan.net.nz>

Fingerprint: 1B470A1C043AB115A99638E048682904DEE27C7D
UserID: Ondřej Čertík <ondrej.certik@gmail.com>
UserID: Ondřej Čertík <ondrej@certik.cz>

Fingerprint: 2FE2163F611C80BE2BF5EE6248D19F46BC99C9B7
UserID: Lee Garrett <debian@rocketjump.eu>
UserID: Lee Garrett <lgarrett@rocketjump.eu>
UserID: Mark Lee Garrett <lee+gnupg@rocketjump.eu>

Fingerprint: 140F202C78F643A57CE8B8F449C3BF8927553D2E
UserID: Guido Trotter <ultrotter@debian.org>
UserID: Guido Trotter <ultrotter@quaqua.net>

Fingerprint: 6CD068620DE13D1B938572334B0069CCF6527847
UserID: Bruno Kleinert <fuddl@debian.org>
UserID: Bruno Kleinert <fuddl@mailbox.org>
UserID: Bruno Kleinert <fuddl@tauware.de>

Fingerprint: 5C48FE6157F49179597087C64C5A6BAB12D2A7AE
UserID: Christoph Berg <cb@df7cb.de>
UserID: Christoph Berg <christoph.berg@credativ.de>
UserID: Christoph Berg <myon@debian.org>
UserID: Christoph Berg <myon@oftc.net>

Fingerprint: 07CA87DDC4C2B06240B6B1745041F1891F44E090
UserID: A. Maitland Bottoms (aa4hs) <bottoms@debian.org>

Fingerprint: F75FBFCD771DEB5E9C86050550C3634D3A291CF9
UserID: Philipp Kern
UserID: Philipp Kern <phil@philkern.de>
UserID: Philipp Kern <pkern@debian.org>

Fingerprint: 50BC7CF939D20C272A6B065652B6BBD953968D1B
UserID: Dmitry Smirnov <onlyjob@cpan.org>
UserID: Dmitry Smirnov <onlyjob@debian.org>
UserID: Dmitry Smirnov <onlyjob@disroot.org>
UserID: Dmitry Smirnov <onlyjob@member.fsf.org>
UserID: Dmitry Smirnov <onlyjob@posteo.net>
UserID: Dmitry Smirnov <onlyjob@riseup.net>

Fingerprint: F00C9F2F4F7EB714AFAD1A42538C0766F4BCB38E
UserID: Clint Byrum <cbyrum@godaddy.com>
UserID: Clint Byrum <cbyrum@spamaps.org>
UserID: Clint Byrum <cbyrum@us.ibm.com>
UserID: Clint Byrum <clint.byrum@canonical.com>
UserID: Clint Byrum <clint@fewbar.com>
UserID: Clint Byrum <clint@goodmoney.com>
UserID: Clint Byrum <clint@ubuntu.com>
UserID: Clint Byrum <spamaps@debian.org>

Fingerprint: 6E7434F5897D43B17FCD57B753D5BC64B52378A2
UserID: Scott Talbert <swt@techie.net>

Fingerprint: 0EED77DC41D760FDE44035FF5556A34E04A3610B
UserID: Sascha Steinbiss <sascha@steinbiss.name>
UserID: Sascha Steinbiss <satta@debian.org>
UserID: Sascha Steinbiss <satta@tetrinetsucht.de>
UserID: Sascha Steinbiss <ss34@sanger.ac.uk>
UserID: Sascha Steinbiss <steinbiss@zbh.uni-hamburg.de>

Fingerprint: 12CCFE48BAD829BBD6BFFE3D566217F3C4395C9C
UserID: Piotr Roszatycki <dexter@cpan.org>
UserID: Piotr Roszatycki <dexter@debian.org>

Fingerprint: 930BB50F68C747D2A0E70FA4566E861304468DEC
UserID: Al Nikolov <clown@debian.org>
UserID: Al Nikolov <root@toor.fi.eu.org>
UserID: Al Nikolov <roottoorfieuorg@gmail.com>

Fingerprint: A7400F5A48FB42B8CEE8638B5759F35001AA4A64
UserID: Steve Langasek <steve.langasek@canonical.com>
UserID: Steve Langasek <steve.langasek@ubuntu.com>
UserID: Steve Langasek <vorlon@debian.org>
UserID: Steve Langasek <vorlon@dodds.net>

Fingerprint: 3B21B8E68AE5C16F87F5322D5792783B206FEE30
UserID: Sophie Brun <sophie@freexian.com>
UserID: Sophie Brun <sophie@offensive-security.com>
UserID: Sophie Brun <sophieb@debian.org>

Fingerprint: B8FAC2E250475B8CE940A91957930DAB0B86B067
UserID: Joost E. van Baal (Nederland, 1970)
UserID: Joost van Baal <J.E.vanBaal@uvt.nl>
UserID: Joost van Baal <joostvb@ad1810.com>
UserID: Joost van Baal <joostvb@debian.org>
UserID: Joost van Baal <joostvb@enosig.org>
UserID: Joost van Baal <joostvb@logreport.org>
UserID: Joost van Baal <joostvb@mdcc.cx>
UserID: Joost van Baal-Ilić

Fingerprint: 59E895A48D09D6C8EBB94CE857E7C6324F81391D
UserID: Sergei Golovan <sergei@golovan.ru>
UserID: Sergei Golovan <sgolovan@debian.org>
UserID: Sergei Golovan <sgolovan@nes.ru>

Fingerprint: B73823B302F8A2426FCA1BBE590AE197EF123736
UserID: Juliane Friederike Holzt <juliane@holzt.de>
UserID: Juliane Holzt <juliane@holzt.de>

Fingerprint: 17EF07E6F59E9F3E16E0C0A259EC43D65246508B
UserID: Dale E. Martin <dale@the-martins.org>
UserID: Dale E. Martin <dmartin@debian.org>

Fingerprint: 1C9A2574B1A48D8AC243CAE55C29137271246E4A
UserID: Muammar El Khatib (Debian) <muammarelkhatib@gmail.com>
UserID: Muammar El Khatib <muammar@debian.org>

Fingerprint: 6F1D26E46B6612334228B04A5EA2BDB6883CCDE2
UserID: Chen Baozi <baozich@debian.org>
UserID: Chen Baozi <baozich@gmail.com>
UserID: Chen Baozi <cbz@baozis.org>

Fingerprint: 638BC75EC1E5C589067E35DE62645EB35F686A8A
UserID: Mo Zhou <cdluminate@gmail.com>
UserID: Mo Zhou <cdluminate@riseup.net>
UserID: Mo Zhou <lumin@debian.org>
UserID: Mo Zhou <mzhou32@jhu.edu>
UserID: Zhou Mo (Passport) <cdluminate@gmail.com>
UserID: Zhou Mo (master 4096 gmail key) <cdluminate@gmail.com>

Fingerprint: 3006C9FBBFC9CAB82FA38A2A63CE20BAC49C4148
UserID: Tim Cutts (Debian Development) <tjrc1@debian.org>
UserID: Tim Cutts <tim@thecutts.org>
UserID: Tim Cutts <timc@chiark.greenend.org.uk>

Fingerprint: D20D5E7E7BDA7633BEA14A9F67708B14E1C142B1
UserID: Brian White <bcwhite@debian.org>
UserID: Brian White <bcwhite@pobox.com>

Fingerprint: 3DF1A4DFC732468838BCF121686930DD58C338B3
UserID: Marcin Kulisz (kuLa) <debian@kulisz.net>
UserID: Marcin Kulisz <debian@kulisz.net>
UserID: Marcin Kulisz <kula@debian.org>
UserID: Marcin Kulisz <kula@kulisz.net>

Fingerprint: DD9861AB23DC3333892E07A968E713981D1515F8
UserID: Arturo Borrero Gonzalez (Centro Informatico Cientifico de Andalucia - CICA) <aborrero@cica.es>
UserID: Arturo Borrero Gonzalez <aborrero@cica.es>
UserID: Arturo Borrero Gonzalez <aborrero@wikimedia.org>
UserID: Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com>
UserID: Arturo Borrero Gonzalez <arturo@debian.org>
UserID: Arturo Borrero Gonzalez <arturo@netfilter.org>

Fingerprint: D8812F4065320B8DCA3CEF18694CADEF51C7B5B6
UserID: Michael Fladischer (Medical University of Graz) <michael.fladischer@medunigraz.at>
UserID: Michael Fladischer <FladischerMichael@fladi.at>
UserID: Michael Fladischer <fladi@debian.org>
UserID: Michael Fladischer <mfladischer@fladi.at>
UserID: Michael Fladischer <michael.fladischer@fladi.at>
UserID: Michael Fladischer <michael@fladi.at>

Fingerprint: 648DD98F4BC4829017CB0E3469740E5CB35FEC3C
UserID: Eduard Bloch <blade@debian.org>
UserID: Eduard Bloch <edi@gmx.de>

Fingerprint: 2FAFEBB52F5F5DCE5570D2E66C6ACD6417B3ACB1
UserID: Roger SHIMIZU <rogershimizu@gmail.com>
UserID: Roger Shimizu <roger.xc.shimizu@sonymobile.com>
UserID: Roger Shimizu <roger@localet.com>
UserID: Roger Shimizu <rosh@debian.org>

Fingerprint: 20A741B470D74B2077D029E86C7BFF9E99746B65
UserID: Pablo Lorenzzoni (Spectra) <pablo@propus.com.br>
UserID: Pablo Lorenzzoni (Spectra) <spectra@debian.org>

Fingerprint: 4CB7FE1E280ECC90F29A597E6E608B637D8967E9
UserID: Miguel Landaeta (Debian) <nomadium@debian.org>
UserID: Miguel Landaeta (LDC) <miguel@ldc.usb.ve>
UserID: Miguel Landaeta (Open English) <miguel@openenglish.com>
UserID: Miguel Landaeta (Restorando) <miguel@restorando.com>
UserID: Miguel Landaeta <miguel@miguel.cc>
UserID: Miguel Landaeta <nomadium@gmail.com>

Fingerprint: BCA6F0EF11B23F924BA392296FE413326DC4B226
UserID: John H. Robinson, IV <jaqque@debian.org>
UserID: John H. Robinson, IV <jaqque@gmail.com>
UserID: John H. Robinson, IV <jhriv@sbih.org>
UserID: John H. Robinson, IV <jhriv@ucsd.edu>

Fingerprint: BAFC6C85F7CB143FEEB6FB157115AFD07710DCF7
UserID: Ole Streicher <debian@liska.ath.cx>
UserID: Ole Streicher <olebole@debian.org>

Fingerprint: ABE195E150A8DBE7809D3F427127E5ABEEF946C8
UserID: Mirco Bauer <m.bauer@gsd-software.net>
UserID: Mirco Bauer <meebey@debian.org>
UserID: Mirco Bauer <meebey@meebey.net>
UserID: Mirco Bauer <meebey@php.net>
UserID: Mirco Bauer <mirco-b@gmx.de>
UserID: Mirco Bauer <mirco@bauer.name>

Fingerprint: E0FD6DAE7C51262FDAE6A28B7174A18FAAA7A078
UserID: Asias He <asias.hejun@gmail.com>
UserID: Asias He <asias@debian.org>
UserID: Asias He <asias@redhat.com>

Fingerprint: 02054829E12D0F2A8E648E62745C4766D4CACDFF
UserID: Ralf Treinen <treinen@debian.org>

Fingerprint: AE731055442A1D96CF4D4C7875B710635C213A7E
UserID: Hilko Bengen <bengen@debian.org>

Fingerprint: 2AB8EB163CA562E182A13AAE7731FCCC63E4E277
UserID: Roberto C. Sanchez <roberto@connexer.com>
UserID: Roberto C. Sanchez <roberto@familiasanchez.net>
UserID: Roberto C. Sanchez <sanchezr@ieee.org>

Fingerprint: BE3D8AF066B6EC8079667FD777C1D22D53E15F02
UserID: Joachim Bauch <bauch@struktur.de>
UserID: Joachim Bauch <jojo@struktur.de>
UserID: Joachim Bauch <mail@joachim-bauch.de>

Fingerprint: F5E11B9FFE911146F41D953D78A1B4DFE8F9C57E
UserID: Ludovic Rousseau <ludovic.rousseau@free.fr>
UserID: Ludovic Rousseau <rousseau@debian.org>

Fingerprint: C6045C813887B77C2DFF97A57C56ACFE947897D8
UserID: Anibal Monsalve Salazar <anibal@debian.org>
UserID: Anibal Monsalve Salazar <anibal@kernel.org>

Fingerprint: EB3345F56441B8B81A7798767DFA41AD961985D7
UserID: Gennaro Oliva <gennaro.oliva@cnr.it>
UserID: Gennaro Oliva <gennaro.oliva@gmail.com>
UserID: Gennaro Oliva <oliva.g@na.icar.cnr.it>
UserID: Gennaro Oliva <oliva@debian.org>

Fingerprint: 3453B5A2F40603D7FF9FFAF07E0A399DB24B3B15
UserID: Matthew Garrett <mjg59@debian.org>
UserID: Matthew Garrett <mjg59@google.com>
UserID: Matthew Garrett <mjg59@srcf.ucam.org>

Fingerprint: B60DB5994D39BEC4D1A95CCF7E6528DA752F1BE1
UserID: Sylvestre Ledru <s@mozilla.com>
UserID: Sylvestre Ledru <sledru@mozilla.com>
UserID: Sylvestre Ledru <sylvestre.ledru@inria.fr>
UserID: Sylvestre Ledru <sylvestre.ledru@scilab.org>
UserID: Sylvestre Ledru <sylvestre@debian.org>
UserID: Sylvestre Ledru <sylvestre@irill.org>
UserID: Sylvestre Ledru <sylvestre@ledru.info>
UserID: Sylvestre Ledru <sylvestre@mozilla.com>
UserID: Sylvestre Ledru <sylvestre@ubuntu.com>

Fingerprint: 91EECA611F18DA32AFA40E2E84CCF98060F105FE
UserID: Klee Dienes <klee.dienes@hadronindustries.com>
UserID: Klee Dienes <klee@alum.mit.edu>
UserID: Klee Dienes <klee@debian.org>
UserID: Klee Dienes <klee@dienesfamily.org>
UserID: Klee Dienes <klee@mit.edu>

Fingerprint: 7E43E9ACBF727AB3CF0885338716CE4614A452D8
UserID: Sebastien Badia <sbadia@debian.org>
UserID: Sebastien Badia <seb@gitoyen.net>
UserID: Sebastien Badia <seb@globenet.org>
UserID: Sebastien Badia <seb@ldn-fai.net>
UserID: Sebastien Badia <seb@sebian.fr>
UserID: Sebastien Badia <sebastien@badia.fr>

Fingerprint: 6583B3EBB874F4544D5D2B23873DEA309D13807F
UserID: Chrysostomos Nanakos <cnanakos@debian.org>
UserID: Nanakos Chrysostomos (Chris) <nanakos@wired-net.gr>

Fingerprint: 1998FD821B7124F525B25133888220B87E798989
UserID: Ari Pollak <ajp@aripollak.com>
UserID: Ari Pollak <ari@debian.org>
UserID: Ari Pollak <aripollak@gmail.com>

Fingerprint: 1DF6A19FCA53F97353F3F35D8A0A48874687AF4F
UserID: Toni Mueller (code signing) <dev@tonimueller.org>
UserID: Toni Mueller <debian@tonimueller.org>
UserID: Toni Mueller <mail@tonimueller.org>
UserID: Toni Mueller <tm@tonimueller.org>
UserID: Toni Mueller <toni@debian.org>

Fingerprint: C2C96B10011FE009E6D1DF828A75D10998012C7E
UserID: Jay Berkenbilt <ejb@ql.org>
UserID: Jay Berkenbilt <qjb@debian.org>

Fingerprint: 1C977AFDCD9B00F2BC509A088C09994F6E48A047
UserID: Ean Schuessler <ean@brainfood.com>
UserID: Ean Schuessler <ean@debian.org>
UserID: Ean Schuessler <ean@novare.net>

Fingerprint: 9FDFBD2937CEC8A249DD4D9C8CBE219C74576D81
UserID: Willi Mann <willi@debian.org>
UserID: Willi Mann <willi@wm1.at>

Fingerprint: 71EDACFC68010DD91AD19B868D1F969A08EEA756
UserID: Dmitry E. Oboukhov <dimka@avanto.org>
UserID: Dmitry E. Oboukhov <dimka@uvw.ru>
UserID: Dmitry E. Oboukhov <rsync@yandex-team.ru>
UserID: Dmitry E. Oboukhov <unera@avanto.org>
UserID: Dmitry E. Oboukhov <unera@debian.org>
UserID: Dmitry E. Oboukhov <unera@uvw.ru>

Fingerprint: 8795AF2E4A1A4EFBA068A4498E889544D985000D
UserID: Bastian Venthur <bastian.venthur@flixbus.com>
UserID: Bastian Venthur <bastian.venthur@tu-berlin.de>
UserID: Bastian Venthur <mail@venthur.de>
UserID: Bastian Venthur <venthur@cs.tu-berlin.de>
UserID: Bastian Venthur <venthur@debian.org>

Fingerprint: 42028EA404A2E9D80AC453148F0E7C2B4522E387
UserID: Bill Allombert <Bill.Allombert@math.u-bordeaux.fr>
UserID: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
UserID: Bill Allombert <ballombe@debian.org>

Fingerprint: 59472423E07FE30FD47A8BB7925252C459797A1D
UserID: Hanno 'Rince' Wagner (Debian-Key) <wagner@debian.org>
UserID: Hanno 'Rince' Wagner (debian-Key) <debian@rince.de>

Fingerprint: 2A62FCF3BBE867727440369C9258A798513F86CD
UserID: Brian Thomason <brian-thomason@ubuntu.com>
UserID: Brian Thomason <brian.thomason@eucalyptus.com>
UserID: Brian Thomason <brian.thomason@gmail.com>

Fingerprint: 795D0851095CAACA16CA79259AFB7B8C9A5F5BBC
UserID: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
UserID: Heiko Stuebner <heiko@sntech.de>
UserID: Heiko Stuebner <mmind@debian.org>
UserID: Heiko Stuebner <mmind@kernel.org>
UserID: Heiko Stübner <heiko@sntech.de>

Fingerprint: 91B46ECD90312D7C86F9469A9BD2D6409A0C52FA
UserID: Laszlo Kajan <kajan@in.tum.de>
UserID: Laszlo Kajan <lkajan@debian.org>
UserID: Laszlo Kajan <lkajan@rostlab.org>

Fingerprint: A8DF13269E5D9A38E57CFAC29D20F6503E338888
UserID: Mike Dotty <dottedmag@debian.org>
UserID: Mike Dotty <dottedmag@dottedmag.net>
UserID: Mikhail Gusarov <dottedmag@altlinux.org>
UserID: Mikhail Gusarov <dottedmag@debian.org>
UserID: Mikhail Gusarov <dottedmag@dottedmag.net>
UserID: Mikhail Gusarov <mikhail.gusarov@gmail.com>

Fingerprint: BAE0340127D536AD2CB12FE09EC002FE1C9CA517
UserID: Michael C. Schultheiss (GSWoT:US74) <schultmc@gswot.org>
UserID: Michael C. Schultheiss (GSWoT:US74) <schultmc@gwot.org>
UserID: Michael C. Schultheiss <michael@amellus.com>
UserID: Michael C. Schultheiss <schultmc@amellus.com>
UserID: Michael C. Schultheiss <schultmc@debconf.org>

[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) <debian.axhn@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.

* 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 <edmonds@debian.org>
UserID: Robert Edmonds <edmonds@fsi.io>
UserID: Robert Edmonds <edmonds@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

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