Quantcast

Change in behaviour for invalid crypto engine

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Change in behaviour for invalid crypto engine

Avram Lubkin
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.

Thanks,

Avram



_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Change in behaviour for invalid crypto engine

Daniel Kahn Gillmor-7
Hi Avram--

On Sun 2017-05-07 00:13:41 -0400, Avram Lubkin wrote:
> 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.

fwiw, gpgme itself ships a python binding (named "gpg") as part of
1.8.0.  that binding is maintained upstream, and you're probably better
off in the long term using it instead of pygpgme.

sorry to not have a concrete answer to your question about pygpgme, just
wanted to clarify the support situation going forward.

       --dkg

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Change in behaviour for invalid crypto engine

Avram Lubkin
On Mon, May 8, 2017 at 6:21 PM, Daniel Kahn Gillmor <[hidden email]> wrote:
fwiw, gpgme itself ships a python binding (named "gpg") as part of
1.8.0.  that binding is maintained upstream, and you're probably better
off in the long term using it instead of pygpgme.

Thanks for the response. I wasn't aware gpgme was including language-specific bindings. I'll have to make sure the functionality matches, but it does seem like a good long term strategy. I had been concerned about the lack of updates from pygpgme.

That said, that won't be something I can tackle in the near future. Assuming there are no issues, in addition to integration with my code, I (or someone else) would need to make Fedora/EPEL RPMs available. I write 3rd party enterprise software, so any 3rd party libraries need to be provided by Red Hat/Centos or Fedora/EPEL. It looks like neither the gpg or pyme python packages are available as RPMs.

Avram


_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Loading...