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