Thoughts on GnuPG and automation

[Hans of Guardian]

On Mar 3, 2015, at 4:43 PM, Peter Lebbing wrote:

> On 03/03/15 14:29, Hans of Guardian wrote:
>> It is actually more difficult to wrap GPGME in Java than to have just
>> rewritten GPGME in Java.
> 
> In my opinion, if this is the case, then that is indeed the proper
> solution: write a general-purpose library à la GPGME, but don't call gpg
> directly from your application.
> 
> Calling the gpg binary is indeed an API, as was said here. It's the API
> GPGME uses, for instance. GPGME does not somehow load gpg in its address
> space or something; it simply invokes gpg, in a separate process.
> 
> That calling the gpg binary is an API doesn't make it the right API for
> other programs to use. The right API in general would be GPGME or an
> alternative to GPGME.
> 
> Just like libc is the proper API for a program to use instead of
> directly issuing syscalls to the Linux kernel. The syscall interface is
> an API; it's just not the right one in many cases.
> 
> At least, this is my view of it.
> 
> Peter.

Different programming languages and operating systems can have very different ways of launching and handling external processes.  By forcing them all to launch GPG in the UNIX way makes for complicated and weird software.  For example, Android works very differently than any UNIX or even Windows, especially when it comes to launching and managing processes.

At the risk of being repetitive: Android runs the Linux kernel, but is it far far far from being UNIX or GNU/Linux.

.hc