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? > > 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
