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. 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
signature.asc
Description: This is a digitally signed message part
