GnuPG 2.4.4 still using legacy packets?
Jakob Bohm
jb-gnumlists at wisemo.com
Thu Nov 13 13:35:02 CET 2025
On 13/11/2025 12:56, Andrew Gallagher via Gnupg-users wrote:
> Hi, Peter.
>
> On 13/11/2025 09:23, Peter Pentchev wrote:
>> - so, IF NO `--rfc...` OPTION IS SPECIFIED, GnuPG HAS TO default to
>> the least common denominator
>
> This is not how GnuPG's compliance options currently work though;
> non-default compliance options cause GnuPG to comply with *earlier*
> specs, to improve backwards compatibility at the expense of
> cryptographic strength.
>
> It would be reasonable, and still solidly defensive, for GnuPG to emit
> the old packet framing iff a compliance option such as --rfc2440 was
> supplied, or if the key being encrypted to advertised old defaults, or
> if the key material uses an algorithm or packet version that pre-dates
> rfc4880. But it serves no purpose to continue to use the old format
> with modern cryptography that legacy code can't understand anyway.
>
The important open questions are:
1. Since what version and year does gnupg accept the new framing of
packets that it can also accept with old framing? This controls when
senders will be able to use the new framing by default.
2. Since what year do all then-and-later commonly distributed OpenPGP
implementations accept the new framing of packets that gnupg can send
with old framing? This controls when gnupg will be able to send the new
framing by default.
3. If either of the above questions are answered by "recent" (for
enterprise-frozen values of "recent"), should gnupg add options to
specify that the recipient follows a newer spec, such as rfc-4880, and
can thus decode the new framing of old packet types and can also handle
the new packet types introduced by that "newer spec"? Such an option
might be named --rfc4880plus or --no-rfc2440 (meaning don't implicitly
trigger option --rfc2440, but be careful not to create a contradictory
corner case where --rfc2440 is not the exact negative of --no-rfc2440).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
More information about the Gnupg-users
mailing list