gpgme "Locate engine names only at runtime and prefer GnuPG-2" commit break Android

[Hans-Christoph Steiner]

On 02/21/2014 07:26 AM, Werner Koch wrote:
> On Thu, 20 Feb 2014 21:38, hans at guardianproject.info said:
> 
>> >From what I've seen, gpgme is a wrapper that calls the GnuPG command line
>> tools (gpg2, gpgsm, gpg-agent, etc) to do the actual work.  That arrangement
>> will always be fragile on Android.  That arrangement will also mean it will be
> 
> What you are saying is that Android is more fragile and hardder to work
> with than the ancient Windows Mobile 6 which works very well using gpgme
> despit ethat it is really limited in almost all areas.

What I am saying is that Android works quite differently than UNIX, and even
Windows Mobile 6 is closer to UNIX than Android.  From what I've seen, GnuPG
is built very much on UNIX assumptions, and those mostly work on even old
Windows.  But those don't really work on Android.  This is what makes GnuPG
fragile on Android.  To make matters more confusing, Android does provide a
super stripped down, UNIX-ish environment that can do some very basic UNIX
things (i.e. `adb shell`).  But apps do not run in this UNIX-ish environment.
 You cannot login to `adb shell` and run an app directly.  In order to start
an app, you must send a message to the system requesting that app to start
(the command line util for sending that message is called `am`).

That super stripped down UNIX env is what allows us to run GnuPG and other GNU
and UNIX tools at all on Android.  But this is not an officially supported way
of working Android, and OS updates often break aspects of it.  (Android 4.4.2
basically broke all of our apps that use these techniques).

Ideally, GnuPG/gpgme would only use function calls, not execs and pipes.  Env
vars should never be required for operation.


>> very difficult to make native-feeling APIs in languages like Java and Python.
> 
> We have several language bindings both high and low-level.  So I don't
> understand your reasoning.  After all GnuPG is not different from GPGME
> - it uses Unix domain sockets and pipes for IPC as well.  Java bindings
> are available for 10 years of even longer.

There are many gpgme bindings, that is true.  From my experience in C, Java,
and Python, those bindings require the Java and Python programmer to work in
ways that are quite unfamiliar, things like the data structures used, how to
iterate thru collections of data, how streams are represented and passed
around, etc.  So Java and Python bindings have existed for a long time, but
the ones based on GnuPG are barely used (esp. the Java ones).  BouncyCastle
and pycrypto dominate in their languages, IMHO because it feels the most
natural.  The GnuPG suite offers all the functionality with a much better
track record for security.

.hc

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81