Thoughts on GnuPG and automation

Ville Määttä mailing-lists at
Wed Mar 4 22:04:52 CET 2015

On 04.03.15 18:21, Bjarni Runar Einarsson wrote:
> 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.

Separation of concerns. Separating different, sufficiently unrelated,
functionality into their own layer / process / service can be just as
beneficial as on a normal *NIX using multiple processes to achieve a
given task. I.e. the so called "UNIX philosophy" [1].

> OpenSSL wrapper libraries for Python are a prime example, for one. More
> code: more bugs.

Implementing something in one monolithic binary instead of two or more
separate binaries does not necessarily mean much more code. We can
always screw up wherever the functionality is.

> 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.

I'm not taking sides one way or the other right now on this one…

> With two layers of wrappers, we have to wait for GPGME to get updated
> and THEN wait for the Python wrappers to get updated.

With separate layers they can be updated separately. There is no need
for every single GPG user to update the binary if a change in some
layered feature needs to be updated.

If features live in a separate layer, certainly there needs to be some
coordination and care that a change does not break some dependant layer.
But that's not really anything new and one needs to always be careful
with such things whether with monolithic and modular binaries alike.

> A well defined protocol also
> has the potential to eliminate mountains of platform-specific hacks

So it has.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150304/a0ac4b85/attachment.sig>

More information about the Gnupg-users mailing list