Change in behaviour for invalid crypto engine

Avram Lubkin aviso at
Sun May 7 06:13:41 CEST 2017

I'm using GPGME through the pygpgme and noticed a change in behavior from
the Centos 7 version (1.3.2) and the Fedora 25 version (1.8.0) when an
invalid crypto engine path is used. pygpgme hasn't been updated in years
and the versions are the same, so it seems like the difference is farther
down the stack in GPGME.

With the following python code:

>>> import gpgme
>>> gpg = gpgme.Context()
>>> gpg.set_engine_info(gpgme.PROTOCOL_OpenPGP, '/not/a/real/path', None)
>>> gpg.keylist()

I raise an exception with GPGME 1.3.2

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
gpgme.GpgmeError: (7, 150, u'Invalid crypto engine')

And I get an empty list with GPGME 1.8.0

I think the desired behavior would be to throw an error or in some other
way inform the user they aren't using a valid engine.

The gpgme.Context.set_engine_info method maps to gpgme_ctx_set_engine_info
in GPGME and always returns None. I'm not sure if any errors get thrown by
GPGME that aren't properly captured by pygpgme. If so, I can open a bug
there for them to capture it.

I tried looking through the GPGME code, but it was hard to follow so any
help would be appreciated. I'd just like to allow my users to point to a
different executable if desired and properly inform them if they configure
one that isn't invalid.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170507/fcb7bb63/attachment.html>

More information about the Gnupg-devel mailing list