[Gpg4win-devel] 64-bit gpgme looking for 32-bit gnupg (was "Re: Gpg4win without claws")

Andrej Kacian andrej at kacian.sk
Tue Sep 20 13:25:34 CEST 2016


Hello,

I would like to revisit the issue of a 3rd party provided GpgME library
finding gpg components from Gpg4win.

It works for us great for 32-bit Claws Mail, but we recently started
working on a 64-bit version, and found out that 64-bit GpgME can not
find what it needs.

Let's quote Werner here:

On Tue, 04 Aug 2015 18:49:11 +0200
Werner Koch <wk at gnupg.org> wrote:

> We may want to solve one problem here right away: gpgme looks for gpg2
> by locating gpgconf in the installation directory of the gpgme DLL.
> 
> Now Claws will install its own gpgme DLL (the glib version) and thus
> gpgme can't find gpgconf using the standard way and will use a
> fallback.
> 
> GPGME locates GnuPG by looking for gpgconf.exe here:
> 
>   1. Install directory of the used gpgme DLL or the application if
>      statically linked.
> 
>   2. Using the registry key "HKLM\Software\GNU\GnuPG:Install
> Directory".
> 
>   3. Below CSIDL_PROGRAM_FILES in the directory "GNU\GnuPG".
> 
> If that all does not work gpgme will try to use gpg 1.4.
> 
> So this won't be a problem with current Gpg4win because that is indeed
> installed at (3).

For a 32-bit GpgMe, options (2) and (3) both work, but they do not
work anymore for a 64-bit GpgME:

Registry key is not found, because on 64-bit Windows, it is virtualized
away in HKEY_LOCAL_MACHINE/Software/Wow6432Node/GNU/GnuPG (as all
32-bit applications' keys are), where 64-bit process can't find them
without kludgy hacks.

Looking in CSIDL_PROGRAM_FILES doesn't work, because a 64-bit
application resolves that to "C:\Program Files", while Gpg4win, is in
"C:\Program Files (x86)".

I'm not sure how to solve this properly, but one idea would be for GpgME
to also look for the required binaries, or at least for gpgconf.exe, in
locations in the PATH environment variable - Gpg4win already adds its
"pub" dir there, after all, and calling "gpgconf.exe" from any
working path works just fine because of that.

Regards,
-- 
Andrej
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20160920/56ded2a3/attachment.sig>


More information about the Gpg4win-devel mailing list