Thoughts on GnuPG and automation

Peter Lebbing peter at
Fri Feb 27 15:09:01 CET 2015

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.



I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <>

More information about the Gnupg-users mailing list