Problem with gpgme in gpg4win 1.1.3

Marcus Brinkmann marcus.brinkmann at ruhr-uni-bochum.de
Mon Apr 7 16:18:54 CEST 2008


At Sat, 05 Apr 2008 09:38:09 -0400,
Igor Belyi <gpgme at katehok.ac93.org> wrote:
> I ran into the problem when a different than default directory is 
> selected during gpg4win 1.1.3 install.

Should be fixed in the upcoming 1.9/2 releases of gpg4win.

> It manifests itself when gpa.exe 
> is started and fails to find the engine. It is caused by mismatch 
> between gpg4win using newer approach of registering "Install Directory" 
> and "gpgProgram" strings in "HKLM\Software\GNU\GnuPG\" key and GPGME 
> relying on either "HKCU\Software\GNU\GnuPG\gpgProgram" (note the HKCU vs 
> HKLM) or on the program being in the default location.

GPGME checks HKCU and falls back on HKLM.  In any case, gpgProgram
should not really be set, there was some confusion and error.  Some
tools like winpt set it, that should be reported as a bug.

> There's a note in 
> the "src/inst-gnupg.nsi" of the gpg4win source saying that relying on 
> "gpgProgram" key is an old style and sure enough the newer version of 
> GPGME (although also 1.1.6, just like in gpg4win 1.1.3) does uses the 
> "Install Directory" to find all the necessary gpg.exe, gpgsm.exe, and 
> gpgconf.exe.

Right.
 
> On related note, the new GPGME still checks for gpgProgram in HKCU and 
> not HKLM rooted location.

That's useful for manual override.

> On my machine I noticed that there was an 
> entry in there which looks like left-over from some previous 
> installation and (as expected) it is not removed by the newer version of 
> gpg4win on install/uninstall. This caused even newer GPGME to assume a 
> wrong location for gpg.exe. I removed that registry value on my machine 
> but I suspect other users may run into similar problem.

We can not remove it reliably at installation time because it can be a
per-user setting.  The new GUI, kleopatra, will check for the registry
key, present a warning and allow to remove it.  In the long haul,
gpgProgram should almost never be present.

Thanks,
Marcus




More information about the Gnupg-devel mailing list