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

[Hans-Christoph Steiner]

On 02/20/2014 02:19 PM, Werner Koch wrote:
> On Thu, 20 Feb 2014 17:43, hans at guardianproject.info said:
> 
>> I understand that gpgme is a wrapper.  The issue is having an Android wrapper
> 
> No, GPGME is not a wrapper.  GPGME is an API to several crypto
> protocols.  The current implementation makes use of GnuPG.
> 
>> So I would like to discuss what needs to happen in GnuPG itself to enable us
>> to write such a thing.  This architecture would also work in other situation,
> 
> For example EasyPG resembles the GPGME API for EMACS but nevertheless
> has lots of problems incompatibilities with newer GnuPG versions.  I
> consider it better to use GPGME because we can guarantee that the GPGME
> API stays stable and that new stable feature of GnuPG will soon be
> reflected by the GPGME API.
> 
>> for example a python wrapper of gpg-agent.
> 
> gpg-agent is not enough.  It is a useful tool but I guess it does only
> make sense if you are using gpg or gpgsm anyway.  And then you should
> use GPGME which also provides an easy to use interface to gpg-agent. 

>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
very difficult to make native-feeling APIs in languages like Java and Python.
 That makes it harder for Java and Python developers to use GnuPG in their
apps.  It also means it is more likely that the API will be misused, leading
to security issues.

.hc

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