Sep 21 2021
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.
Sep 20 2021
- >>gpg2 --version
gpg (GnuPG) 2.0.30 (Gpg4win 2.3.3)
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?
Aug 13 2021
Jun 25 2021
Jun 24 2021
Apr 15 2021
Feb 13 2021
There is still useful software working only with 2.7. So it is not the time to drop this.
Feb 12 2021
Feb 9 2021
Jan 28 2021
Jan 19 2021
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:
Jan 18 2021
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.)
Jan 5 2021
|we do it for the other bindings as well.|
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.
Dec 3 2020
Thanks. Fixed in rM7a4fe82a017b: python: Fix key_export*..
Nov 20 2020
Nov 19 2020
Oct 28 2020
Pushed the change.
Oct 27 2020
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
Sep 18 2020
Jul 15 2020
Apr 20 2020
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.
Apr 19 2020
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.
Aug 27 2019
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.
Jul 8 2019
yes, python2.7 and python3.7
Using several python versions?
Jun 21 2019
Jun 19 2019
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.
Jun 4 2019
I tried to apply&push, since we changed the file a bit, I needed to apply it manually.
Anyway, it's done.
May 6 2019
Merged. Thanks again for your work on this.
Thanks for the explanation. That addresses my concerns.
May 3 2019
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.