[openpgp] Deprecating compression support
Werner Koch
wk at gnupg.org
Tue Mar 26 22:36:43 CET 2019
On Tue, 26 Mar 2019 17:11, dkg at fifthhorseman.net said:
> ilf is asking about a change to the advertised preferences included in
> an OpenPGP certificate generated by default with GnuPG.
I got that.
> Someone who wants to use the compression feature because they know
> that's what they want needs only to issue a "setpref" command to
Just using setpref instead of using the defaults is not easy but may
require new organizational procedures and training.
> This is not breakage exactly -- it's a question of where we want to push
> the ecosystem.
I see no reason to drop compression form OpenPGP. It has been there
forever and is a part of it. Those folks who are trying to get severe
last minute changes into a revision of a standard may be better off to
start their protocol from scratch.
> definition, then it seems like we could well do it with a switch to a
> new key format. What did you mean here?
At some point new keys will be generated in v5 format and it will be
hard enough to get systems adopted to the longer fingerprint. Forcing
people to change their entire processing by adding another tool into a
list of steps to encrypt and convey data is everything else than user
friendly.
> can you elaborate on this? In contexts where OpenPGP is not only used
> for e-mail, it's not competing with S/MIME, and it seems likely that a
> simple pipeline with gzip or xz or whatever can meet the use case.
You need to change established procedures, test the new setup, fix the
bugs, have meetings with your peers to agree on the changes, and so on.
It is basically a the deployment of a new product.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190326/71543217/attachment-0001.sig>
More information about the Gnupg-devel
mailing list