Thoughts on GnuPG and automation
Hans of Guardian
hans at guardianproject.info
Wed Mar 4 00:57:46 CET 2015
On Mar 3, 2015, at 8:52 PM, Werner Koch wrote:
> On Tue, 3 Mar 2015 14:29, hans at guardianproject.info said:
>> 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
> Sorry, but that is not your problem. The problem on Android seems to be
> that it is not easy to install anything else than plain Java apps.
> We have GPGME bindings for all kind of languages from Ada over Java to
> Scheme. Thus I can't see the problem - need another kind of data object
> to be handled in GPGME? No problem, it can easily be done. Is the
> event loop the problem? That is somewhat harder to get right but that
> is always the case if you use a library.
> I don't really understand your complaints given that we worked together
> to port GnuPG to Android. GPGME is just a small thing on top of it and
> way easier than GnuPG itself. It has nothing to do with fork+exec -
> GnuPG uses that itself a lot.
> In 2010 we ported GnuPG and GPGME and Kontact (includes KMail) to
> Windows Mobile 6.5. I can tell you, that was a task but we finally did
> it. And the problems were not due to GnuPG (even that it ate up many of
> the scarce process slots) but due to the shear amount of memory KDE
> stuff required. Consider as an example this: On Windows CE (the kernel
> of Windows Mobile), you don't have stdout and stdin, nor is there a way
> to inherit or pass on file descriptors.
And that is why this thread is going on, so hopefully we can come to an agreement that there are many areas where GnuPG can be used but GPGME is a bad solution to do it. That is all I ask really from this thread at this point. The bizarre Java wrapper of GPGME was not the biggest part of the problem of the GnuPG-for-Android port, but it was nonetheless a real problem. Sure it is possible to use GPGME with Java, but it is not good, and ill-fitting APIs make for bad software, which in turn often leads to bad security. It also took a lot of time. In retrospect, I think it would have been quicker to write a native GPGME in Java on Android than to continue the work on the gnupg-for-java wrapper.
Now I'm trying to convey my experience of what I learned by actually getting GPGME working on Android, and how the situation can be improved. It turns out that I came to some quite similar conclusions to the mailpile team: there needs to be a shared interface for native frameworks, GPGME is not the way for many popular environments.
More information about the Gnupg-users