GnuPG 2.4.4 still using legacy packets?

[Peter Pentchev]

On Thu, Nov 13, 2025 at 08:22:39AM +0100, Loup Vaillant wrote:
> > > Let's be honest, interoperability has not ben an issues for likely
> > > more than a decade. [...]
> > 
> > Ah, but that is conditional on interoperability not being an issue.
> 
> As I said, it's not.  Hasn't been for many years.
> 
> Remember, the ability to read the new framing became at least a SHOULD 27
> years ago.  18 years ago, the new packet types made it a MUST.
> 
> Can anyone name *one* OpenPGP implementation in notable use today that still
> cannot understand the new framing?  There isn't, right?

You'd be surprised what software runs on internal corporate systems that
were set up literally thirty years ago and that were maybe, *maybe*,
upgraded twice since then, with extremely careful testing and
extremely conservative upgrade paths. You may be surprised at what some
tools written last year may need to produce so that some of those
installations can consume it.

So here we come to what I think is the most important point missed by
some of the people in this thread: TL;DR: gnupg has the `--rfc2440`,
`--rfc4880`, and `--rfc4880bis` options; use them as appropriate.

Somewhat more verbose TL;DR: for various tools that support several
output formats, it is actually good practice to specify the exact format
that you want, even if you think it really should be the default or
if it is the current default.

The longer version:
- standards change with time
- implementations change their defaults with time
- these changed defaults may cause problems down the road; see e.g. how
  various Linux distributions (I know for certain about Fedora and Debian,
  there may be others) had a bit of work to do recently when GCC 15
  switched to a new C language standard by default (if the -std option
  was not specified!), and it started failing to compile programs that
  used something that, in my personal opinion, was obsolete twenty years
  ago, but there was still source code like that out there
- yes, it would be nice if stuff could "just work" without additional
  options
- no, it is not possible in the real world
- so, always specify as many standards-compliance and output-format
  options as you can think of; yes, this makes some command-lines
  longer that they might possibly need to be to work today, you will
  be glad you did in three years (or fifteen years) time

And the longer version, *specifically* pertaining to GnuPG:
- AFAIK, GnuPG has always had interoperability in mind (my personal
  opinion about the recent, um, differences in opinion within
  the OpenPGP working group is irrelevant here)
- interoperability includes "this version of GnuPG should not change
  its behavior when invoked by ancient tooling that aims to produce
  output to be consumed by even more ancient tooling"
- so, IF NO `--rfc...` OPTION IS SPECIFIED, GnuPG HAS TO default to
  the least common denominator

G'luck,
Peter

-- 
Peter Pentchev  roam at ringlet.net roam at debian.org peter at morpheusly.com
PGP key:        https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251113/62f61172/attachment.sig>