A couple usability hurdles with GCC release signatures

[Richard Biener]

On Tue, Sep 29, 2026 at 5:37 PM Mark Wielaard <mark@klomp.org> 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 <gcc@gcc.gnu.org> 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