Thoughts on GnuPG and automation

[Hans-Christoph Steiner]

Bjarni Runar Einarsson wrote:
> Hello GnuPG users!
> 
> I just published a follow-up to Smári's blog post about the Mailpile
> team's frustration while working with GnuPG. The post is here:
> 
>    https://www.mailpile.is/blog/2015-02-26_Revisiting_the_GnuPG_discussion.html
> 
> As it's rather long, I won't paste the whole thing in here, but I do
> welcome any and all feedback. The gist of it is: the GnuPG CLI is not
> very well suited for automation and the 2.x design appears to make some
> things we want to do almost impossible.
> 
> Corrections (if I made any factual errors) will be posted to the web
> ASAP, and I'll link back to this thread in the archives so webby people
> can see your replies. I hope this qualifies as constructive critism!
> 
> As I said on our IRC channel: If we're lucky it'll be a humiliating
> "you're just doing it wrong, here is the solution". ;-)
> 
> Cheers,
>  - Bjarni
> 
> -- 
> Sent using Mailpile, Free Software from www.mailpile.is

As the lead dev on the Android port of GnuPG, I definitely can share your pain
on working with the GnuPG suite.  For example, GnuPG is built heavily around
UNIX assumptions, and Android is not UNIX at all, and it is much further from
UNIX than Windows is.  We ultimately got pinentry working on Android, with
much struggle.  After going through that, I also had lots of grips, which I
probably should have written up like you did.

With all the recent attention to GnuPG and Werner's work, I have begun to
think about things differently.  GnuPG has an amazing security track record.
It has had few serious security bugs, nothing even close to heartbleed that I
know of, and yet it is core to providing security to GNU/Linux distros, as
well as protecting people like Laura Poitras and Edward Snowden.  So instead
of complaining about the difficulties, I now try to think about whether such
difficulties might actually be related to what makes GnuPG so solid.  I think
anyone interested in providing usable security needs to think hard about this.
 Sure we can make things easier to use, but it is a very slippery slope
towards reducing security.

I also have to call out that part of the problem that mailpile is continuing:
it is generally more fun to write code, rather than figure out someone else's
library.  That is especially true when its a complicated thing like GnuPG.
But in order to have shared maintenance and work, we all need to take
responsibility and try to build upon the work of others whenever possible.
Mailpile did not do that, and instead wrote yet another incomplete python API
for GnuPG.

Now all that said, we definitely need to be debating how to improve working
with GnuPG so that we can build software that is intuitive and private by
design, on top of the solid GnuPG track record.  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).

Another possibility is making ASSUAN, the internal protocol between GnuPG
components, the API instead of `gpg --json`. This only works on GnuPG 2.1, as
far as I understand it, since in 2.1, even commands like gpg communicate with
gpg-agent using ASSUAN, and it is actually gpg-agent that does all the work.
Contrary to the mailpile write-ups, I think that having all the work happen in
gpg-agent makes sense, as long as there is a good API to it.

.hc


-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81