gpgme "Locate engine names only at runtime and prefer GnuPG-2" commit break Android
hans at guardianproject.info
Thu Feb 20 17:43:39 CET 2014
On 02/20/2014 11:18 AM, Werner Koch wrote:
> On Thu, 20 Feb 2014 16:30, hans at guardianproject.info said:
>> In this situation, PATH won't do anything useful by default on Android.
>> Android is not UNIX, apps do not install things into the PATH. Also, apps are
> You mean gpgconf is not installed in a directory listed by PATH? Well,
> then why not hard code the directory for Android?
>> not supposed to change env vars, that's inherited from Java, which only has
>> getenv(), no setenv().
>> A hard-coded path to each thing that gpgme calls is the best approach that I
>> can think of for Android. While technically possible to change the PATH, we
> Okay - which path? Build time configuration or runtime configuration?
> A fixed directory for Android seems to be the best appraoch
Yes, a build time config is perfect.
>> have wasted sooooo many hours with kludges like that. Its not the right
>> approach for Android.
> PATH is a standard Unix and Windows feature to locate executables.
That much I know... :)
>> to either implement gpgme in Java, or even better, implement a library that
>> talks directly to gpg-agent via assuan like the gpg command line do. There
> Actually gpgme is such a library.
I understand that gpgme is a wrapper. The issue is having an Android wrapper
of a Java wrapper of a gpgme wrapper of gpg-agent is very hard to work with.
Having an Android wrapper of a Java wrapper would be a lot especially if
sometimes the Android native code can skip the Java wrapper and speak directly
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 a python wrapper of gpg-agent.
PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81
More information about the Gnupg-devel