On 9/29/26 2:27 PM, 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).
`gpg2 --digest-algo SHA512 -b file` should use SHA512, AIUI. Also, it is
my understanding that `personal-digest-preferences SHA512 SHA384 SHA256`
in gpg.conf would make it the default directly without having to use
--digest-algo.
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
