Fixed in gpgme 1.21.0.

For reference, here is a link to the gpgme homebrew formula:
https://github.com/Homebrew/homebrew-core/blob/master/Formula/g/gpgme.rb

Just to clarify, PIP wasn't used to install the .egg package. The package was built and installed via Homebrew. The error message occurs when using basic PIP commands such as pip list or pip freeze. PIP is picking up the gpgme egg from the shortcut included in the site-packages directory.

We don't use or suggest the use of PIP or other insecure software distribution systems.

Should be fixed now; see commit above.

FWIW: WriteFile and write are more different than in using a HANDLE vs. a libc file descriptor. Despite that a HANDLE might be a 64 bit pointer, it is guaranteed that the value fits into a 32 bit variable. But they still index different objects. The return code and error values are also different.

Much simpler: write is only used in the callbacks and over there gpgme_io_writen[n] shall be used anyway.

it's not hard to fix that header to actually provide a sensible write(), avoiding the issue listed on the mailing list, where there was no return to check:

@ikloecker Thanks for your comment. I put a comment in the commit.

Note that this may not work for Python 2.7, but since those are just examples that doesn't matter that much.

So, here are fixes. I'll apply soonish.

In T6466#169934, @werner wrote:

Funny enough that Python seems not to allow to set the permission with open. Low priority because a proper umask must anyway be used on a multi-user system.

Funny enough that Python seems not to allow to set the permission with open. Low priority because a proper umask must anyway be used on a multi-user system.

Fixed in 1.19.0.

Will go into 1.19.0

That's why I added some tags and also set me a reminder. We will try to get this into the next GPGME release we plan for this month.

@werner Seeing as you seem to be actively maintaining this project: is there any way to move this forward? This is breaking quite a few builds of development environments for my company and we are now applying similar patches ourselves but it would be nice to get this merged upstream.

OK I can confirm that with ae9258fb and f1802682 commits I was ble to update my rpm packages to 1.18.0.

@gniibe - Thanks for the quick response. It now works for me.
cu Andreas

@ametzler1 Thank you. That was because of my bad fix.
Fixed in rMf1802682c3c8: python: Fix configure generating setup.py.

the pushed fix breaks when libgpg-error does not require special CFLAGS, i.e. when @GPG_ERROR_CFLAGS@ expands to an empty string:

Pushed the fix.
Note that non-in-tree build never been reliable (using the result of the configure, in tree).
So, I basically don't consider the use case of non-in-tree build.

Reviewing the build process, it's just better to use @...VAR...@ by configure (instead of invoke pkg-config again in setup.py).

Indeed, you are right. The object created by with can be valid even after the context (when referenced by another object).

Not sure if that is the complete fix - if you do something like:

with gpg.Context(...) as context:
    ...
... cause an exception after the context has been closed ...

then context will still be a valid reference to the gpg.Context instance, and may cause segfaults when something tries to access things inside it (f.e. for serialisation).
I like your previous solution with the accessor checks, because that actually fixes the issue.
Stylistically, maybe __del__ should just be renamed to cleanup or free, and then make sure to call that function from both __exit__ and __del__.

I think the fix should be something like this:

diff --git a/lang/python/src/core.py b/lang/python/src/core.py
index 81f961d9..95fd0cba 100644
--- a/lang/python/src/core.py
+++ b/lang/python/src/core.py
@@ -1189,8 +1189,9 @@ class Context(GpgmeWrapper):
     def __enter__(self):
         return self

@jap Thank you.

Can confirm, we've been running into this as well, but never filed a bug report. Our solution is to have this in our codebase:

The SEGV was due to access to gpgme library after self.wrapped is set to None in the __del__ function.

GnuPG 2.0 reached end-of-life nearly 4 years ago. See https://gnupg.org/download/index.html#end-of-life . Same for Gpg4win. They are not maintained and its use is very risky due to unfixed bugs. Please update to a recent version.

1. >>gpg2 --version

gpg (GnuPG) 2.0.30 (Gpg4win 2.3.3)
libgcrypt 1.6.6

Which gpg version?
Which Python library? (gnupg is pretty generic)
How does the Python library call gpg?
Are you aware that gpg uses utf8 and not Windows Unicode?

There is still useful software working only with 2.7. So it is not the time to drop this.

Dependency hell - ask your favorite distribution

Can you point me to a more elaborate list of the general concerns? (Central directories offer some sort of stable history, namespace and API service towards identifying modules, just like the venerable https://www.ctan.org/ . The solutions built on such services, like programming environment specific "package" and dependency managers that download and install thousands of packages automatically (like yarn) may be debatable, but I am not aware of much general concern against the services itself.)

Typo, sorry. I have no access to pypi and won't apply for an account due to general concerns about those platforms. Thus I can't change that page. Let me assign you this issue ;-)

@werner, that is a missunderstanding:

No, this is a fork and we consider the use of a PyPy for GPGME a Bad Thing because it does not guarantee a stable ABI and we accept bugs files against this version.

I may attempt an update here, who has the pypi maintenance account?
(If we don't have it, we need to ask Justin or create a ticket with the PSF.)

The C++, CL, Javascript and QT Bindings are all written by hand.

Hi Werner,

can you elaborate?

Given all the resources we had put on this Python bindings I'd suggest to bite the bullet and replace Swig by handcrafted bindings. More work but we do it for the other bindings as well.

Thanks. Fixed in rM7a4fe82a017b: python: Fix key_export*..

Pushed the change.

IIUC, fix can be like this:

diff --git a/lang/python/src/core.py b/lang/python/src/core.py
index 996c3b0f..646bbc60 100644
--- a/lang/python/src/core.py
+++ b/lang/python/src/core.py
@@ -147,7 +147,12 @@ class GpgmeWrapper(object):
                     gpgme.gpg_raise_callback_exception(slf)
                 return result

On further thought, it's possible that something closer to what
Bernhard wants (and incidentally more along the lines of what I was
thinking of in some of our discussions just after the initial port)
might be achievable with Cython.

FWIW, GPGME is basically C90 and we only recently started to use C99 variadic macros - they are a cpp feature, though.

CFFI has no real means of generating the needed bindings on the fly
like SWIG does, except via its ABI methods, but those are inferior to
what SWIG does. It also can't handle all the ifdefs (or really any of
the ifdefs) in gpgme.h.

i'm actually running make -j3 check, since make -j3 distcheck has the problems described in T4688.

So i've been able to (intermittently) reproduce the failures that i think @werner was alluding to here, but not under any circumstances where i can get them to happen reliably to understand what's going on.

yes, python2.7 and python3.7

Using several python versions?

rM7d0a979c07d2 disabled the test for this. @werner says:

I note that "the best" seems like it might be a pretty subjective thing. The standard GnuPG framing asks about the validity of keys for the User ID in question. Perhaps the caller could indicate whether they want to require full validity for each key to make this key selection more strict.

The function would do something like:

• from msg, extract all e-mail addresses from to, cc, bcc fields
• find "the best" keys that match these addresses, storing them in keylist
• copy msg to tmp, remove bcc header from tmp
• wrap armored output of gpg.Context.encrypt(bytes(tmp), recipients=keylist) in the necessary RFC 3156 cladding, copying most headers from msg (maybe stubbing out the subject), producing an email.message.EmailMessage object.

I tried to apply&push, since we changed the file a bit, I needed to apply it manually.
Anyway, it's done.
Closing.

Merged. Thanks again for your work on this.

Thanks for the explanation. That addresses my concerns.

I agree that this is a minor API shift, but i *don't* think it's a security problem, because i was particularly careful to maintain the invariant that decrypt(verify=True) will only ever return valid signatures.

I'm for merging this as I understand the rationale. In Kleo / GpgOL I also only need one valid signature.

I've just published a branch dkg/fix-T4276 (with commit 4100794e305ba22241ea5a4f7b42bb5189fbd948) which i think resolves this issue.

@dkg If you propose a patch here I'm pretty sure that we will accept it. As one of our Python binding users you know better then us how the API should behave.

Reading through this issue and the related documentation: Thanks for writing this all down and adding links!

I sent a message to gnupg-devel about this issue as it will probably hit more people now that the keys used are expired :-(

Oh,.. it is even worse. The conflict keys expired 2019-01-06 so they are actually expired right now.