A few thoughts on this as a packager who has seen this category of concern misused to coerce maintainers:
On Tue, Sep 29, 2026 at 3:16 AM John Scott via Gcc <[email protected]> wrote: > I have a use case involving use of the Metalink format (RFC 5854) to refer to > source archives and how they can be obtained This is incredibly pedantic, but why on earth is the RFC with the motivating use case the only one without an authoritative link provided? It is completely impossible to evaluate the necessity of employing any particular signature wrapper format to serve your use case if your use case is not specified. Is it an accepted internet standards document, or does it remain a rough draft like zstd? All of these questions are necessary to take into account when considering whether the gcc project should be making (breaking?) changes to its signature format and particularly to its selection of allowed asymmetric key variants and individual custodians thereof. > In RFC 3156 [1], which is still the authoritative specification for this > media type [2] This presumes IETF standards documents and IANA designations for media formats represent the authoritative specification for cryptographic material used by gcc in its release process. PGP was designed under the assumptions and constraints of email communications, which is certainly well within the wheelhouse of IETF/IANA. One major misalignment that arises when applying that model to publications of software releases is that email is an interpersonal (i.e. bidirectional) communication mode, whereas software publication is typically unidirectional (which is in fact a critical requirement enabling a release tarball to be effectively cached and mirrored). We use application/pgp-signature as a best-effort attempt to adapt the structure of PGP signatures to the purposes of software publication, but when we start to criticize and interrogate that adaptation process, the correct and in fact necessary intermediate step is to holistically revise the trust architecture that motivated the original process, and not to blindly propose the application of standards documents with their own sets of motivations and tradeoffs (none of which are raised in this discussion as of yet). > 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. So the proposal here is that the transformation from binary to ASCII-armored text format (which you are capable of performing yourself) should instead be done by gcc (and the whole cinematic universe of gnu release mirrors), because the Metalink XML format (which you have not linked to nor defined) is incapable of using the (standard) binary encoding for detached signatures (is this last part even true? you have implied this is so, but not actually stated it). It blinks reality to suggest gcc is the only instance where usage of a binary encoding would stimy (?) this mysterious Metalink XML format. Is there a rationale for why ASCII-armored encoding is preferred (?), a design decision that RFC 5854 no doubt made (?) understanding the existence of binary detached signatures? Is this in fact the sort of feedback that could motivate further development of the Metalink XML format instead of playing whack-a-mole with every possible software project publishing detached signatures? As a designer and implementor of detached signature schemes (more on this later), I would never develop a system that depends upon my sources to generate precisely the correct format of signature to unblock my verification of said signature. This is kind of a basic principle of distributed system design. But the gcc team has responded as if this is valid, and I don't mean to derail by injecting my own subjective evaluations of hypothetical system architectures. > 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. This is a bit of a special interest of mine. Are we defining DSA as insecure? Because you certainly imply that it is (the use of "and" is pretty unambiguous in this regard), despite then focusing completely and entirely upon the use of SHA-1. Since you then focus entirely upon SHA-1, let's stick to that. There is much to say about DSA and key width (which fails to specify the specific choice of prime finite field selected during parameter generation and which is the single deciding factor regarding whether a specific DSA key is susceptible to Pohlig-Hellman's 1978 attack using the Sunzi Remainder Theorem, which remains the best attack upon Diffie-Hellman/discrete log), but it's not being said, so we'll focus upon SHA-1. > (It is known that SHA-1 collisions were found by Google several years ago.) Indeed, Google is well known for exerting a great degree of processing power upon generating hash collisions, and is also among the primary contributors to the heinous TLS 1.3 version negotiation method. However, finding a single collision to a Merkle–Damgård construction (an architecture shared by SHA-2, which like MD5 and SHA-1 was designed by Ron Rivest) is not an argument for insecurity, particularly given that any two inputs with a shared prefix will share the same intermediate checksum value and collisions can therefore be computed with tree-structured parallelism and caching. When making a statement such as, and I quote: > the signature is objectively and genuinely insecure it is incredibly crucial to define or at least hint at the category of threat model under which attacks may be carried out by hostile adversaries such as Google. This has not been done, while consequently wielding the threat of insecurity to fundamentally restructure how gcc performs releases. This is, to put it bluntly, not a trustworthy mode of interaction with open source projects, and is very frequently used to introduce changes which can cause further harm than the harm vaguely hinted at by the accuser. > 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. Are you a software packager? Can you link to the policy where we all decided SHA-1 was insecure but not SHA-2? Because the policy links come fast and furious in this email in everywhere except the most important points. Without (yet) getting into questions of distributed system design, the Metalink XML format is not the first consumer of gcc release signatures, but rather software packaging ecosystems that use gcc to build software. Since this is not the appropriate venue to describe the ideal scenario, I will merely state that gentoo's portage uses all three of: - SHA-512 hash - BLAKE2s hash - byte length as checksums, together, to verify downloads from arbitrary mirrors. In particular, while the BLAKE family is far from perfect, tree hashing as a practice can be used to avoid certain categories of shared-prefix attacks upon Merkle–Damgård checksums. The byte length mechanism singlehandedly mitigates a large category of collision attacks. If we were to restructure gcc release verification, I would recommend this approach. > in particular GnuPG has declined to accept patches that would add support for > RFC 9580 (modern OpenPGP) rpgp (which unfortunately requires Rust) has no such qualms. > 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. The theory and practice of """post-quantum""" asymmetric keys through module learning with errors is farcically abysmal, and the implementation of ML-DSA signature verification in the linux kernel was backdoored to contain an early successful exit in the 7.0 rc cycle in March of this year. I have not audited any other implementation, but lattice keys continue to demonstrate well-known flaws, namely being absolutely massive for comparatively little security. This is why the current version of signal's post-quantum ratchet loses the resistance to adversarial randomness which was pioneered by the double ratchet method which relies upon--you guessed it--modular exponentiation over prime finite fields. So the gcc team should know that this is in fact hotly debated among theorists and implementors, and most certainly not an unambiguous security improvement as implied. > 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. As stated above, the brilliant property of modular exponentiation is that the security level is a property of the entire class of keys generated from the same prime finite field, since the best-known attack is the Pohlig-Hellman 1978 approach using the Sunzi Remainder Theorem. This makes any individual key's age less of a liability than the choice of prime finite field. Of course, there is the additional concern of key compromise, which is related to key age. But a key stewarded appropriately (i.e. offline) is not linearly less secure over time. So this characterization of "weak keys" (which completely fails to even mention that the best-known attack on modular exponentiation requires cracking an entire prime field at once, not any individual key) is remarkably irresponsible and primed to coerce the desired behavior without producing a greater understanding of security among the gcc team. > 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. You could perform the translation to text yourself. Why is this not possible? Why would the Metalink XML format (the only standard without a link to any specification) require gcc to make changes and not anyone else? Have you contacted any other projects about this? Has the Metalink XML format engaged with whether this could be a limitation on their end? Is there a reason why you're relying upon downloading signatures on-demand instead of retaining and verifying their contents yourself, something I would consider to be a very basic architectural methodology for any distributed system of shared trust relationships, and particularly necessary for any system of verifying executable code from remote sources? ---------- It is an immense shame that GPG is no longer an ally to projects like gcc which serve as roots of trust for systems of interoperating executable code. It is also an immense task to reproduce what GPG can do elsewhere, so I hope I can be excused for not having an answer to these concerns yet. As used by gentoo's portage, I currently recommend SHA-512+BLAKE2s+byte length, all together, as a system of secure checksums (this is the compromise I have landed upon for a bootstrap process for emacs dependencies I am working on, since I cannot expect everyone to also accept completely new checksum algorithms yet). While I share the OP's desire to improve trust in gcc's release outputs, I believe the post that began this thread to represent a troubling and irresponsible attempt to introduce a change in gcc's security architecture. I would caution the gcc team to regard such overtures with an appropriate degree of skepticism, unless and until there has been sufficient community discussion and consensus achieved on the matter of how to prove trust in a distributed software ecosystem. Thanks, d@nny disc@
