Thoughts on GnuPG and automation

[Hans of Guardian]

On Feb 27, 2015, at 3:09 PM, Peter Lebbing wrote:

> On 27/02/15 12:02, Hans-Christoph Steiner wrote:
>> For example, I think that
>> `gpg --json` is great idea.  I ended up using a Java wrapper of GPGME, which
>> is in turn a wrapper of GnuPG.  I think it makes a lot more sense to have `gpg
>> --json` as the parseble interface, then implement a GPGME-style framework in
>> each language (Python, Java, etc).
> 
> I'd say the JSON interface could just be an additional set of functions in
> GPGME; and GPGME simply talks the old colon-separated protocol to the gpg
> binary. You can't just take out the colon-separated protocol, and that protocol
> has all the information. You could simply have GPGME reformat the output.
> 
> Unless you mean that you want to speak to the gpg binary yourself, without GPGME
> in between. In that, case, I simply think you might be on the wrong track, and
> should use a library. If GPGME itself is a problem because you don't know what
> platform you should compile for, like in Python, then the library could be
> re-implemented in pure Python instead of using a foreign function interface.
> 
> The old calling conventions of the binary cannot change, otherwise you'd break
> everything that already depends on it. And adding multiple ways of doing the
> same thing in the gpg binary seems the wrong place; more code, more chance of
> bugs, etcetera. This is where libraries come in, to save you the burden of
> working with the gpg binary.

It is actually more difficult to wrap GPGME in Java than to have just rewritten GPGME in Java.  GPGME is a fine API for C/C++, it is a bad API for other languages.  You end up with an API that feels like a C API forced into the language, e.g. Java, python, etc.  That makes for more coding mistakes because it feels foreign to the programmer.  More mistakes means more security issues.

.hc