[Gpg4win-devel] [Announce] GPGME 1.1.7 released

[Marcus Brinkmann]

Igor Belyi wrote:
> Marcus Brinkmann wrote:
> I maintain pyme project which is a Python wrapper for gpgme library. To build
> this wrapper I need development components of gpgme (header and library) which
> gpg4win installation does not provide and as a result I build libgpg-error and gpgme
> myself. To use that wrapper on Windows I also need gpgme DLLs in the pyme module
> directory. The idea is that pyme user should be able to use any encrypting/decripting
> engine installed on their computer - it just the follow up on the GPGME claim that its
> "API isn't restricted to this (GnuPG) engine".

It is unfortunate that you need to ship your own copy of gpgme.  I don't know if
python on windows supports dynamic loading of libraries.  If yes, it might be a
good idea to do that, and thus auto-detect if gpgme is installed.

OTOH, you might have a hard time finding gpgme, as we are working on removing
dependencies on registry entries.  However, we can provide a way to do that (by
querying gpgconf, which should be in the PATH).

If that doesn't work for you, you have to keep shipping your own copy of gpgme
on Windows, as we don't provide a stand alone copy of it.

Of course, in any case you need to build your own gpgme to get the development
files.  I am sorry for that, but we currently do not offer official development
packages for Windows, either.

> So far I've based my Windows build on gpg4win 1.1.3 which is listed as a
> current stable release. If I understood you correctly the gpg4win containing the
> updated gpgme is the gpg4win 1.9.12 BETA and probably gpg4win 3.0.0 BETA1. I can try to
> create a separate pyme build for these releases but I'd like to hear your suggestion
> regarding packaging for pyme. I can't include gpgme-w32spawn.exe in pyme since gpgme DLL
> specifically looks for it in GnuPG installation places. In Short, that pyme build
> will not be compatible with gpg4win 1.1.3 or any other previous versions (see "backwards
> compatible as advertised" above). On the other hand, I suspect that build with gpgme
> 1.1.6 would still work with gpg4win 1.9.12 (forward compatible?).

We can modify gpgme to look for the executable in the same directory as its own
DLL, or a subdirectory of it.  This is something we are working towards anyway.
 As I said above, it might be even better to just use the gpgme provided by
gpg4win directly, if feasible with python.

I think the main problem for you is the following case: Installing a pyme that
ships a new gpgme on a system with an old version of gpg4win.  Am I correct that
this is the case bothering you?  It might be possible for you to just link
against an old version of gpgme, which should work with newer gpg4win as well.
But of course we want you to eventually update, maybe some time after gpg4win 2
has been released.

> Also, with such change if somebody else decides to provide its own GnuPG
> implementation they would have to make it Gpgme-enabled by including gpgme-w32spawn.exe
> as well.  This is perfectly reasonable design decision of course it just got me by
> surprise since my understanding was that it was Gpgme job to be adapted to different
> engines and not the other way around. Probably, it would be a bit more in agreement
> with me if GnuPG engine would be specified with gpgme-w32spawn.exe as an executable
> instead of still pointing to gpg.exe but spawning that other program instead.

The spawn program is generic and does not depend on the backend.  It is
necessary to fork/exec a program while controlling tightly the set of inherited
file descriptors (which also need to be renamed).  There is a similar program in
glib 2.0.  Our version has some additional twists to help passing additional
file descriptors on the command line.

Thanks,
Marcus