Properly notify gpgme about spawn executable location on Windows
mikekaganski at hotmail.com
Sat Apr 20 15:32:55 UTC 2019
Hi Thorsten, *,
When working on a 6-0-based branch on Windows, in make check, two python
tests emit modal error dialogs about missing gpgme-w32spawn.exe:
> GpgME not installed correctly
> gpgme-w32spawn.exe was not found in the detected installation directory
> of GpgME
> Crypto operations will not work.
> If you see this it indicates a problem with your installation.
> Please report the problem to your distributor of GpgME.
> Developer's Note: The install dir can be manually set with:
For completeness, the tests are sw_python and
pyuno_pytests_insertremovecells, but this is not really important;
obviously, the tests themselves don't need the initialization of
security context, and the unneeded initialization was fixed somewhere
down the road, and later versions don't block on the tests.
However, I suppose that it's possible in theory that some user python
script could ultimately need initializing gpgme. In that case, the
problem would hit the user. Having a modal dialog waiting on a possibly
headless server is not a correct behavior :-)
The cause here is that by default, gpgme only expects to find the spawn
process in the same location as the current executable (see
_gpgme_get_w32spawn_path and _gpgme_get_inst_dir in
gpgmepp/src/w32-util.c). It works when the executable is soffice.bin;
but for python, which is located in a subdirectory of instdir/program,
this is not true (see error message above). It needs to be told
explicitly where to look for the executable; and it's only possible
using gpgme_set_global_flag call.
So I went ahead and prepared a patch for this:
https://gerrit.libreoffice.org/71014, which adds a check if the spawn
executable is in the same directory as current process executable, and
if not, queries UNO_PATH environment variable to check if it contains
the executable, to notify gpgme about the path.
My questions are:
1. First of all - do I understand it correctly that the problem is real
- so there are possible scenarios involving e.g. python (or another
process which executable is not in LO's instdir/program), that might
need gpgme? I'm not familiar with our scripting framework, so I might
actually invent a non-existing problem after all. I see that problem
happening only with those tests, and I don't know if the later fix has
completely ruled away the possibility to run that code from python, or
just made that called only when really needed (which implies that it
will happen eventually).
2. To find the executable, I use UNO_PATH envvar. As far as I can tell,
even directly running soffice.bin without having UNO_PATH set in
environment, sets the variable correctly, so this works as expected. But
is there a better way?
3. The patch needs to add a gpgmepp wrapper for gpgme_set_global_flag
function, because the function itself is not accessible from the place:
if I simply used it, linking it fails:
> [LNK] Library/xsec_xmlsec.dll
> Creating library C:/lo/src/core/workdir/LinkTarget/Library/ixsec_xmlsec.lib and object C:/lo/src/core/workdir/LinkTarget/Library/ixsec_xmlsec.exp
> SecurityEnvironment.o : error LNK2019: unresolved external symbol gpgme_set_global_flag referenced in function "public: __cdecl SecurityEnvironmentGpg::SecurityEnvironmentGpg(void)" (??0SecurityEnvironmentGpg@@QEAA at XZ)
> C:/lo/src/core/instdir/program/xsec_xmlsec.dll : fatal error LNK1120: 1 unresolved externals
I could overlook how to use the function without the need of the wrapper
- if so, please give me a hint how to do that properly. If there's no
way to do that, then I'll create a pr to https://github.com/KDE/gpgmepp.
More information about the LibreOffice