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.