On Tue, Sep 29, 2026 at 5:37 PM Mark Wielaard <[email protected]> wrote: > > Hi, > > (Added Ian to the CC who might know how to update the process to > include detached "armored" signatures.) > > On Tue, 2026-09-29 at 14:27 +0200, Richard Biener via Gcc wrote: > > On Tue, Sep 29, 2026 at 3:16 AM John Scott via Gcc <[email protected]> wrote: > > > > > > Hello, > > > [Please disregard if these are known problems; I don't mean to complain, > > > but just to make sure this hasn't been overlooked.] > > > > > > I have a use case involving use of the Metalink format (RFC 5854) to > > > refer to source archives and how they can be obtained, and I noticed the > > > GCC release signatures are not very useful as they are. Consider for > > > example: > > > https://ftpmirror.gnu.org/gcc/gcc-16.2.0/gcc-16.2.0.tar.xz > > > https://ftp.gnu.org/gnu/gcc/gcc-16.2.0/gcc-16.2.0.tar.xz.sig > > > > > > The signature has file extension .sig and is served over HTTP with > > > Content-Type: application/pgp-signature, but this doesn't conform to the > > > accepted convention for a detached OpenPGP signature. In RFC 3156 [1], > > > which is still the authoritative specification for this media type [2], > > > it states the detached signature must always be in US-ASCII "armored" > > > text format, but this detached signature is actually in binary format. > > > Using the "armored" text form going forward would be nice. This is a big > > > deal for me for the following reason: if the signature were in the > > > standard text form, I could use an XInclude directive to incorporate the > > > detached signature "by reference" into the Metalink XML, which normally > > > expects the signature data to be in the document. > > > > > > The second problem is that the signature is objectively and genuinely > > > insecure, as Richard Guenther's OpenPGP primary key is a 1024-bit DSA key > > > from 2001, and both subkey binding signatures as well as the signature > > > over the GCC tarball itself were made using SHA-1 as the digest. (It is > > > known that SHA-1 collisions were found by Google several years ago.) > > > Because SHA-1 is distrusted, modern programs won't trust the subkey > > > binding signature nor the signature over the GCC tarball, but regardless > > > the obsolete dsa1024 key means the subkey can't be trusted anyway. > > > This is a more challenging and less tractable problem to fix; in > > > particular GnuPG has declined to accept patches that would add support > > > for RFC 9580 (modern OpenPGP) and it's doubtful they'll ever get > > > conforming post-quantum key support. That would be the ideal choice for > > > developers to generate new keys for signing releases, but it's a > > > difficult situation for distros right now as well. > > > > > > Based on [3] it looks like Jakub Jelinek is the only person authorized to > > > sign GCC releases who isn't dependent on a 25-year-old dsa1024 key, so I > > > don't expect the weak keys/weak signatures problems to be solved anytime > > > soon. (The text on that web page is mildly misleading about Richard's > > > key: the use of RSA merely refers to his subkey.) However uploading > > > armored detached signatures instead of binary ones is, I hope, a much > > > more amenable tweak and one that'll suffice to make the detached > > > signatures at least "legal" instead of malformed. > > > > The GNU manual for maintainers documents gpg2 -b to be used for > > signing the tarball to work with the automatic upload > > procedure for ftp.gnu.org. > > > > Sorry for my old gpg key and for using SHA-1, I'm merely using gpg2 -b > > for signing and the subkey marked for signing is 4096 bits. > > I don't know why gpg defaults to SHA-1 and not a reasonable other > > choice (my build seems to have at least SHA512 enabled as well > > for 'HASH'). If you have suggestions for a better command to sign I'm > > all ears - you possibly also want to raise this (the binary > > signature) with the maintainers of ftp.gnu.org and the GNU maintainers > > manual (I couldn't quickly find the authorative source of it). > > The upload processes (including using gpg -b to create the signature) > are here > https://www.gnu.org/prep/maintain/html_node/Automated-FTP-Uploads.html > > I believe Ian wrote the checker for the uploads (the signature is also > used to check whether the uploader is allowed to release a new version > for the project). Ian, could the process be changed to (also) include > an detached/armored signature?
Said script might want to also reject insecure hashes being used? I stil have to dig how to re-configure my key to use an alternate hash algorithm or what exact option would achieve that ... > > > > Thanks for your understanding. If you could just make the detached > > > signatures be text going forward, I will no longer be barred from > > > including signature information in my Metalink documents. In particular > > > trusting the release signing keys will be a responsibility left to a user > > > agent or client program, a detail I can be content not worrying about. > > > > > > [1] https://www.rfc-editor.org/rfc/rfc3156.html#section-9.2 > > > [2] https://www.iana.org/assignments/media-types/application/pgp-signature > > > [3] https://gcc.gnu.org/mirrors.html
