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