GPGME Python bindings

Ben McGinnes ben at
Fri Dec 29 22:24:39 CET 2017

On Thu, Dec 28, 2017 at 05:49:58PM -0500, Leo Famulari wrote:
> Hello,
> I'm working on downstream packaging of GPGME and GPGME's Python
> language bindings for GNU Guix. [0]


> Because it was easier, we began packaging the GPGME Python bindings
> based on the PyPi release [1] of version 1.8.0.
> However, since that time, GPGME has had a few more releases, but the
> PyPi release has not been updated.

Nor is it likely to be at the moment, PyPi is ... one of the least
impressive aspects of Python, unfortunately.

> How should we interpret this? Does it mean that we should continue to
> package version 1.8.0 of Python bindings? Or should we try to build them
> from the latest GPGME source release?

The Python bindings are updated with each GPGME release and compiling
GPGME should result in the current bindings being built and installed
in the versions of Python 2 and 3 found on the system.

IIRC the bindings with GPGME 1.8.0 used the module name of gpgme, that
has since been changed to gpg. and current behaviour is very pythonic.

For example, here's about the simplest clear signing method (using the
default key of the user running the code):

    import gpg
    from gpg.constants.sig import mode

    with gpg.Context() as c:
        signed = c.sign(b"Test message", mode=mode.CLEAR)

    afile = open("filename.txt.asc", "wb")

Encryption and decryption don't require much more than that either.

Yes, you can encrypt data as a class and then import that upon
decryption if your intent is to securely store authentication tokens
as part of something else.  In fact, that's what prompted what led to
these bindings being updated to Python 3 in the first place.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <>

More information about the Gnupg-users mailing list