Thoughts on GnuPG and automation

[Bjarni Runar Einarsson]

Werner Koch <wk at gnupg.org> wrote:
> 
> > I think that one solution would be to have mailpile use a per-session
> > gpg home dir.
> 
> That is an architectural decision.
> 
> BTW, gpg-agent has this --extra-socket feature which distinguishes
> between remote and local use (modulo some discussed changes).  It would
> be easy to extend it in a way that gpg can tell gpg-agent to act as if
> it was used via --extra-socket.

Hi Werner!

In order to use that in current releases of GnuPG, then Mailpile needs
to run its own gpg-agent, correct? And in order to use a custom pinentry
as discussed elsewhere? Can I run multiple agents off the same keychain,
or do I also need to create a separate gpg home dir for each one?

I ask, because although current users of GnuPG are proportionally very
few, they are still a group I consider important. I expect many such
users to become quite annoyed if Mailpile doesn't integrate cleanly with
their existing keychain.

Regarding other topics broached on this thread, I think it is very
interesting to hear that GPGME is basically the "official"
implementation of something that wraps the gpg binary. I hadn't looked
deeply enough into GPGME to be aware of this.

I will probably take a peek at the GPGME source to see if I missed some
more elegant ways to solve things. In particular, both generating keys
and editing the UID list on a key are quite gross in Mailpile's wrapper
and I wonder if GPGME offers a better implementation?

GPGME proponents will be frustrated to hear that this knowledge actually
makes me feel much better about Mailpile's decision to wrap gpg
directly: it means I've removed two layers of abstraction between my
code and gpg! Win! Although supposedly such layers are supposed to help
developers (and people will continue to accuse me of NIH and whatnot),
in my experience on other projects, they've more often than not been
sources of additional architectural constraints and bugs of their own.
OpenSSL wrapper libraries for Python are a prime example, for one. More
code: more bugs.

This is one of the reasons having a native "protocol" such as JSON or
Assuan in the gpg binary itself (or the gpg-agent if things move there)
appeals to me so much.

With a well designed protocol, wrapper libraries almost become
unnecessary and layers and layers of code can just be stripped away and
discarded. Consider that with a protocol approach, new features in gpg
become available immediately to all applications speaking the protocol.
With two layers of wrappers, we have to wait for GPGME to get updated
and THEN wait for the Python wrappers to get updated. We're all
overworked, so removing layers that need to be kept up-to-date and in
lockstep is a hugely valuable investment. A well defined protocol also
has the potential to eliminate mountains of platform-specific hacks - if
you can talk to the protocol server, things work, no matter whether it's
a fifo in the file system, stdio or a TCP/IP connection to a remote box.
So people can choose the transport that best suits their platform and
just get on with "real work".

Anyway, I'm very glad this discussion is taking place. In my opinion, if
GnuPG wants to be a platform other apps can build on, these interfaces
matter a great deal. Whether there are hacks or workarounds is kind of
irrelevant; if developers are unhappy they'll just go develop something
else. This stuff matters.

Thanks for the comments,
 - Bjarni

-- 
Sent using Mailpile, Free Software from www.mailpile.is
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP Digital Signature
URL: </pipermail/attachments/20150304/dc274886/attachment.sig>