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.
I checked specifically the 16.2 signature and I see
> gpg2 --list-packets gcc-16.2.0.tar.xz.sig
# off=0 ctb=89 tag=2 hlen=3 plen=307
:signature packet: algo 1, keyid 3AB00996FC26A641
version 4, created 1786091352, md5len 0, sigclass 0x00
digest algo 8, begin of digest 82 84
hashed subpkt 33 len 21 (issuer fpr v4
7F74F97C103468EE5D750B583AB00996FC26A641)
hashed subpkt 2 len 4 (sig created 2026-08-07)
subpkt 16 len 8 (issuer key ID 3AB00996FC26A641)
data: [2048 bits]
which shows the hash algorithm used is SHA-256 (digest algo 8) and the
signing key is 2048 bits RSA.
So what is exactly your complaint?
Richard.
(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.
>
> 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
