Thoughts on GnuPG and automation

Hans of Guardian hans at guardianproject.info
Tue Mar 3 14:29:38 CET 2015


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


More information about the Gnupg-users mailing list