DO NOT USE THIS LIBRARY: Includes critical bug (global monkey-patch which breaks unicode and email sending!)

[jannschu]

This library has a serious bug, see #244. The short story is: A global change in the error handling of unicode decoding breaks Pythons MIME code and potentially other things. See the comments in issue #49.

The maintainer has, as stated in the README, not much time to spend on this project (not blaming). This issue tries to warn potential users as long as the issues persists.

An alternative might be the "gpg" package, maintained by GnuPG iteself. It is a binding to the GpgME library. The downside is, that this package has a low level C-like API for certain operations.

Edit: Btw, the claim in the README regarding the shell injection is no longer up to date. The python-gnupg package by vinaysajip seems to be actively maintained.

Edit2: See #246 (comment) for a blog post by @isislovecruft (written before this issue was opened).

[lindhe]

@isislovecruft Is this true? If so, I think this issue should be marked as important and a disclaimer put in the README.

[jannschu]

There is pull request #219 which would add a note to the README, it is open since January 2018.

It is safe to assume that the project is no longer maintained. Sadly, the README indicates that this fork is an improvement over python-gnupg ("a rewrite") and it is found prominently on Google. Its api it not comaptible and the quality is worse (see some of the open issues), though.

From the issues referenced above you can see that several people have spent many hours to find that this library introduces serious problems. I opened this issue to make potential users have a closer look.

The changes from #219 are not enough. Given that @isislovecruft is still active on Github, it is in my opionion very unresponsable to keep the README in the current state. The sentence about python-gnupg's shell injection must be removed and the open problems should be stated in order to prevent people burning significant time. Adding such a note takes one minute, I am not sure why it is not done.

I wish @github would provide a way for the community to do something in such cases. Like a banner above the README.

[alexvh]

This project also has bugs that are rudely dismissed by the maintainer (#135). It's unfortunate that there's no mechanism in GitHub to prevent issues like this and instead let an inferior, unnecessarily complex project squat on another project's name.

[jannschu]

Here is a blog article from June 2018 by @isislovecruft. One claim there is that the shell injection in python-gnupg is not fixed properly despite the notice on the development page. Sadly, I can not tell who is right here. On the hand, I see serious bugs in this project, on the other hand, the article states that serious issues in the python-gnupg project were not taken seriously by the maintainer, technically and personally.

I will not look further. Maybe the conclusion of the article is the right way to go:

If you’re a developer thinking of making a new tool or product based on the OpenPGP protocol: please don’t. Literally use anything else. [...]

If you’re a user or potential user of GnuPG: please don’t. Try using tools with safer, constant-time cryptographic implementations, better code, nicer and more inclusive development teams, and a better overall user experience, like Signal.

[specious]

If you’re a user or potential user of GnuPG: please don’t. Try using tools with safer, ...

Which projects can be considered serious alternatives to GnuPG?

[jannschu]

Maybe https://sequoia-pgp.org/

[clach04]

Here is a blog article from June 2018 by @isislovecruft. One claim there is that the shell injection in python-gnupg is not fixed properly despite the notice on the development page. Sadly, I can not tell who is right here. On the hand, I see serious bugs in this project, on the other hand, the article states that serious issues in the python-gnupg project were not taken seriously by the maintainer, technically and personally.

I will not look further. Maybe the conclusion of the article is the right way to go:

If you’re a developer thinking of making a new tool or product based on the OpenPGP protocol: please don’t. Literally use anything else. [...]
If you’re a user or potential user of GnuPG: please don’t. Try using tools with safer, constant-time cryptographic implementations, better code, nicer and more inclusive development teams, and a better overall user experience, like Signal.

Thanks for posting this. I have no idea either, I'm looking for a way to read gpg encrypted files. I did try out the proof-of-concept script in that article with https://github.com/vsajip/python-gnupg

>>> gnupg.__version__
'0.5.0'

which as of 2023-03-05 is the latest version (latest dev version https://github.com/vsajip/python-gnupg/blob/6081e55ccb513a478a64eaa48e993cb40853851e/gnupg.py#L46 '0.5.1.dev0')

with:

$ gpg --version
gpg (GnuPG) 2.2.19
libgcrypt 1.8.5
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/pi/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

and each of the three POCs report False.

RE alternatives. age https://github.com/FiloSottile/age is on my todo list to check out properly.

Sequioa doesn't have binaries available yet so I'm not sure it is ready for most novice users (like myself).