GnuPG 2.4.4 still using legacy packets?

[Loup Vaillant]

I have to say, what I'm seing for my first interaction with this mailing 
list doesn't encourage me to stick around.  I'll try not to waste too 
much of your time.  Still, I feel compelled to correct a couple 
reasoning flaws.

---

First, a note on the meaning of the word "obsolete".
Just so we understand each other.

To me, and I believe most people, "obsolete" does *not* mean "we can 
drop support right now".  It just means it is time to deprecate it.  The 
way that happens for wire formats (at least those who have a version 
marker) is always the same:

1. Have all readers support both formats.
2. Have all writers output the new format.
3. Let readers drop support for the old format.

When there are very few implementations, the process can be very quick. 
Or it can take forever, if some popular implementation keeps outputting 
the old format decades after the new is supported by all readers.

---

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

In 1998, RFC 2440 introduced a new packet header format.
That new format subsumes the old format.
The new format is required for packets types 16 and higher.
In 2007, RFC 4880 introduced packets 17, 18, and 19.

It would be hard, given the above, to argue that the old format wasn't 
obsolete in 2007.  They didn't say "obsolete" or "deprecated", but still:

- Any fully compliant RFC 2440 reader has to understand the new format.
- Any fully compliant RFC 4880 writer has to sometimes write in the new
   format.

There's also a reasonable argument to be made that deprecation should 
have started as soon as 1998.  I'm personally in that camp, though I 
understand reluctance to do so before 2007, since there was no 
substantial official functionality behind it yet.


> Yes, but *why* was the language strngthened from RFC-4880 to more
> strongly prefer the newer format?

I can make an educated guess: despite the lenient wording of RFC 2440 
and RFC 2880, it is pretty obvious to me that the old format should have 
been deprecated since at least 2007.  The stronger wording is a signal 
to implementers who haven't gotten the memo, so hopefully phase (2) of 
the deprecation process can finally complete.  It is simply the right 
thing to do.

Now of course, I base my guess on two important premises:

- The new format is needed to support functionality from RFC 4880.
- The new format subsumes the old format.

Or in simpler terms, the new format is simply better.  Of course we 
should support only that one, instead of both formats.


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

That, my friend, is circular reasoning.  A form of "Might Makes Right".

It should be obvious by now why we should drop it.  Again:
- It is subsumed by the new format.
- The new format is needed to support RFC 4880.

Once that's established, the onus is on you to show why we should 
support both formats, instead of just one.

Unless GnuPG doesn't read nor write packets of type 17, 18, or 19?  I 
would be genuinely surprised.  Or maybe the header writing logic has 
been duplicated, and the necessary refactoring is difficult?


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

Unless of course practice is bad.  Which it is.  It only takes one 
popular implementation to keep outputting the old format to force 
everyone else to support reading both formats.  Which is more complex 
and more bug prone.  _At scale._

And I am beginning to suspect GnuPG is the only popular application that 
still outputs the old format by default.  I know it's a fairly minor 
detail: the additional format represents less than 30 lines of code in a 
properly written code base.  Still, for an application that is supposed 
to promote security that is quite the bad look.  Please don't do that.

Loup.