GnuPG 2.4.4 still using legacy packets?

[Andrew Gallagher]

Hi, Bruce.

On 11/11/2025 12:11, Bruce Walzer via Gnupg-users wrote:
>
> No preference is expressed at all in RFC-2440. So it appears that
> RFC-9580 is simply incorrect.
...
> So RFC-9580 is also incorrect for RFC-4880 as well.

It is neither accurate nor helpful to use the term "incorrect". None of 
these documents claim correctness, they are merely specifications. That 
means that they can and will differ; it does not mean that any of them 
are more "correct" than any other. All that you can say is that some of 
them are more recent than others.

> I don't know the
> reasoning behind RFC-9580 changing this to "SHOULD NOT" and why the
> incorrect language was used.

Surely the reason is obvious? It is desirable in general to gracefully 
sunset legacy formats. As you have pointed out already, the 
specification changed between RFC2440 and RFC4880, to explicitly prefer 
the newer format (with caveats). RFC9580 merely strengthens the language 
again to more strongly prefer the newer format. This seems to me to be a 
natural evolution of the spec.

> You would probably have to ask on the
> appropriate mailing list to find out if anyone from that faction still
> knows, is still around, and is interested enough to answer your
> question.

This backhanded snark is unbecoming of you, Bruce. The authors of 
RFC9580 are named individuals - three of whom currently work on PGP 
software, and one of those (Niibe) works on GnuPG. Your insinuation that 
RFC9580 was written by shadowy, disinterested figures is an insult to 
its authors, and you should consider issuing an apology.

For reference, the relevant mailing list is openpgp at lists.ietf.org 
(https://mailarchive.ietf.org/arch/browse/openpgp/)
> There doesn't seem to be any practical reason to use a new packet
> header if the packet tag is less than 16. Otherwise you *have* to use
> a new packet header.

The practical reason is that the implementers want the ability 
(eventually) to drop support for the legacy format. This can't be done 
if today's software is still generating it. Considering that all 
RFC2440-compatible software (i.e. anything written in the last 25 years) 
MUST implement the modern format, any software that cannot read it is so 
far out of date that it doesn't support any modern cryptography either 
(for example, it won't support MDC) so is not safe for use anyway, other 
than to read prehistoric archives.

A