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 [email protected] [email protected] [email protected] PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gnupg-users
