GnuPG 2.4.4 still using legacy packets?

Bruce Walzer bwalzer at 59.ca
Tue Nov 11 21:57:16 CET 2025


On Tue, Nov 11, 2025 at 02:59:30PM +0000, Andrew Gallagher via Gnupg-users wrote:
> 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.

RFC-9580 states:

>...as the Legacy packet format was obsoleted by [RFC2440] in 1998.

That statement is literally incorrect for RFC2440. So I don't really
know what you mean here. It is simply wrong and I don't see how any
further discussion is possible.

> 
> > 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.

Yes, but *why* was the language strngthened from RFC-4880 to more
strongly prefer the newer format? That is the question at hand. You
can't just claim some inevitable trend in the pursuit of that
question, particularly in this case where it seems that whoever
modified this section incorrectly thought that the old packet format
had been obsoleted in RFC2440. Perhaps that person might feel
differently in light of the corrected information.

> 
> > 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.

If I am insulting someone here, then those someones don't really
exist. This is based on more than one experience. I would go to ITEF
openpgp mailing list and ask why something was the way it was in the
draft that eventually became RFC-9580. In each case I came bath with
the impression that the original proponent was no longer around or was
no longer responding. That's understandable for a process that spanned
so many years, but it is still a thing.

> 
> 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.

*Why* drop it? I happen to know that a popular implementation (GnuPG)
generates old packet headers as a matter of course and has been doing
that since forever. So the usage is completely standard in
practice. If you want to change the RFC-4880 wording then you have an
obligation to first convince the implementations to discontinue
use. Standaards should follow practice, not the other way around.

Bruce



More information about the Gnupg-users mailing list