installing gnupg 2.2 as "gpg", vs coexistence with gpg 1.4

Daniel Kahn Gillmor dkg at fifthhorseman.net
Mon Oct 9 16:28:39 CEST 2017


On Mon 2017-10-09 03:56:32 +0200, Mihai Moldovan wrote:
> Have you considered that 1.4 is widely used on constraint systems that
> want to avoid dependencies like the plague for automated tasks that
> don't require agent support?
>
> Signature verification would be one of such use cases.

If the only thing you want to do is signature verification, you should
be using gpgv, not the full GnuPG suite.  coincidentally, gpgv requires
no agent support.

If you're using gpgv, you should use the modern (2.1.x/2.2.x) version of
gpgv, since it is capable of verifying more signatures than the
"classic" (1.4.x) version.  for example, ECC and ed25519 signatures
cannot be verified by "classic" gpgv.

I like minimal systems as well, and help to maintain several such
systems.  But when i hear "avoid dependencies like the plague", i wonder
what the specific purpose of that avoidance is.  Is it about bytes on
the storage medium? bytes in RAM?  worries about software maintenance?
concerns about complexity?  Do those issues really outweigh more-active
upstream support, and wider compatibility?  RAM and storage today are
cheap.  and split-out dependencies (e.g. libgcrypt) actually should make
updates and security maintenance easier.

I'm not saying there are no cases where GnuPG's "classic" model could
possibly be useful; but i'm saying that asking upstream to maintain two
divergent branches indefinitely may not be the best use of the
constrained amount of software engineering hours we have available.

   --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20171009/248c13f9/attachment.sig>


More information about the Gnupg-devel mailing list