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.
Apr 20 2020
On further thought, it's possible that something closer to what
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 13 2019
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.
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.
Mar 19 2019
@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.
Mar 12 2019
Reading through this issue and the related documentation: Thanks for writing this all down and adding links!
Jan 9 2019
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.
I don't know why @BenM closed this bug given that he mentioned that the qt part is yet not solved.
Jan 8 2019
We've run into the testTofuConflict failure on NixOS. gpgme v1.12, gnupg v2.2.12.
Dec 15 2018
Though not directly related to our issues, this bug report on the MSYS2 site reported by their users encountering trouble with GPGME provides additional weight to irreconcilable differences between MSYS2 and GnuPG:
Dec 10 2018
Though apparently resolved back in May, this is what ultimately led to T4191 and was thus only properly resolved quite recently.
Confirmed that this is indeed fixed and made the (rather minor) change to the HOWTO that was needed. No changes were needed for the example script (decrypt-file.py).
This has now been tested on a 32-bit Gentoo VM and it behaves as expected with 32-bit system detection and creating keys with pre-2038 expirations working.
Dec 8 2018
Commit 8613727f1ee985c3cfa2c815523312914f033ffd adds considerable detail on both the issues affecting compiling and installing a Windows version of the bindings and what it would take to actually resolve it.
Dec 6 2018
I'll deploy one on AWS somewhere briefly once I've replaced a certain external keyboard, there will almost certainly be an existing image of some Linux distro in the AWS marketplace and I'd be very surprised if it took more than an hour or two of compute time to confirm.
Dec 5 2018
One more semantic question about how folks think Context.decrypt(verify=True) should work: if the decrypted thing has no signature at all, should the function succeed without throwing an exception? it currently does, but the returned verify_result has its signatures member set to the empty list.
Ooh, nice catch @dkg, I just stepped through each of your changes and it all looks good. I'll tweak the relevant sections of the HOWTO dealing with this in the next few days (I need to replace a keyboard here before properly diving back in) and then close this case once done.
@aheinecke thanks for the merge of my other branch! sadly, that branch does *not* address this issue yet. It doesn't even test for it. :( I can work on trying to fix it (and test it) if there's a consensus that we want this particular change in behavior.
Is this fixed now?
Ben is not even subscribed to this issue.
With the volatility of gpgme-python I think that this can easily be merged. I did a quick review and it looked good to me.
Needs to be merged. (Note that Phabricator does not show the branch in the tooltip for commit ids.)
note that the branch also updates the test suite to make sure the verify=False case is tested.
I've just pushed a branch dkg/fix-T4271 , currently at ac8d7238dbf165950c9844e5cb41da8eb4d37bc0 that resolves this problem.
Nov 28 2018
Regression introduced with 1.12.0.
Nov 27 2018
please add a unit to the test suite to make sure something like this doesn't happen in the future!
Nov 22 2018
i'd be happy to help you set up your own x86 32-bit guest VM for testing
if you like, even if you're running on x86_64 hardware. they're cheap
and easy to run, and have a delightfully small memory footprint :P just
let me know!
Nov 5 2018
I consider this bug to be solved.
Nov 3 2018
MacPorts doesn't currently ship the bindings at all, but I'll see what they need to make that a reality too.
While this is now ideal for Debian, it may cause conflicts with other downstream vendors with slightly different needs to build their packages. In particular the FreeBSD ports and/or pkg system.
Oct 29 2018
Oct 20 2018
Nesting the op_genkey() calls inside try/except statements with the exceptions being caught as "oops" and otherwise "oops" being set to None provides a means of checking whether the 2099 expiration is a problem and 2037 is not.
Well, I guess this answers my question in T4192 regarding why op_genkey was in use.
Interesting, I'll look into it, but is there a reason for using op_genkey instead of create_key (optionally with create_subkey and/or key_add_uid)? The latter should be easier and more pythonic.
This should already be possible, iirc the Arch Linux maintainer patched
it in. I believe there is a 'prepare' target that takes care of all the
preparations (duh), and then you can build for every Python version by
executing the Python build system with the Python version of your choice.
Oct 19 2018
Oct 18 2018
That is up to @BenM
the error i'd seen earlier after reverting the change was an error due to running t-callbacks.py on its own, without the rest of the test suite framework. running it within the test suite framework (with the change reverted), it passes without a problem. I've uploaded 1.12.0-4 to debian with a patch to t-callbacks.py. I can apply it upstream, if you want me to.
See T4195 for the general problem
I have not looked at the new error but the year 2099 is clearly a y2k38 problem. gpg has some precautions but I have not checked the key generation code. The gpgme interface uses a signed long for the expiration time, although that it parses the dates received from gpg as an unsigned long. Right now, I am not sure why we did this because an unsigned long would just work. Maybe we can change or enhance the interface. But in any case this is a general problem and not specific to this bug.
@BenM thinks that swig is still the best option. Actually this case helped to find a bug in gpgme. See my next commit.
The error might have to do with rM46da79e3de99a7b65748994921d6aab73b9974e7 which looks like it might run afoul of 32-bit time_t (Y2K38 problem?).
here's me running just the specific test:
If the swig interface isn't robust, can we replace it with something that will be more robust? Or do we need to wrap it with hand-crafted error checks that describe the API's constraints? It's pretty bad form to segfault python.
When parms is malformed but not NULL, then the error appears to be a bug in the python bindings in _wrap_gpgme_release. maybe something is going wrong because of the "cannot allocate memory" error? in particular:
That swig based interface is not really robust and it can't be because it does not known about API requirements. I bet there are other places where mandatory parameters are not checked.
To deal with passing None correctly, it looks to me like the problem is inside get_parameter() in src/genkey.c -- there ought to be a check for parms being NULL, and then returning either GPG_ERR_INV_VALUE or something else. otherwise, the segfault happens inside strstr.
It the first error (first param = None) is a segfault in versions 1.11.1-2 (debian unstable i386) and 1.8.0-3+b2 (debian stretch amd64).
Is this new in gpgme 1.12 or might it also be in older versions?
Oct 17 2018
"dkg (Daniel Kahn Gillmor)" <email@example.com> writes:
what's the status on this? i'd love to be able to build binaries for
both python3.6 and 3.7 for debian. as it stands right now, the
python3.7 continuous integration test for debian is failing
what's the status on this? i'd love to be able to build binaries for both python3.6 and 3.7 for debian. as it stands right now, the python3.7 continuous integration test for debian is failing.
Aug 9 2018
Ok i saw they apply custom patches to _gpgme_mkstemp which are outdated and should be revisited, sorry for the noise
Aug 8 2018
Actually i have now more debug output and i think i found the issue
I close this for now, this seems a problem of the mingw packages in msys2
Aug 7 2018
Or with both packages installed, could i maybe debug somehow where it searches?
BenM, msys2 uses pacman as packagemanager, all packages are build from source
Alternatively, if they wish to keep using the Python installer from python.org then they would need to drop MSys2 in favour of the same version of Microsoft Visual Studio used to compile the that specific version of Python with and use it to compile every part of the GnuPG stack, up to and including GPGME.
If that is indeed the case and the theory regarding runtime conflicts, currently under investigation in T3505 and T4086, also proves to be true; then MSys2 users and developers will need to cease using the precompiled versions of Python available from python.org and compile their own version of Python copy with MSys2.
Windows 10 was obtained last week and the process of preparing a Windows build env began earlier today.
Jul 25 2018
This question and some of the answers to it on StackOverflow indicate some of the difficulties in getting SWIG generated Python modules to install at all. Essentially, though the easiest method currently available without extensive customisation of the setup.py file which would need to be done for both Python 2.7 and Python 3.x is to run /path/to/specific/pythonX.Y setup.py build and then follow that with /path/to/specific/pythonX.Y setup.py install and then follow that with renaming lang/python/build to a relevant directory and/or path name which indicates which version of python was used and the location or path it is in.
Jul 23 2018
While performing some initial investigation regarding observed discrepancies between compiling GPGME directly and the subsequent SWIG static object for T4086, confirmed the relative ease by which multiple installations would be achievable if performed as a post-build process. This would have the added advantage of being more readily customisable by package maintainers downstream and not just for Debian, it could be made to work more easily with other distributions or other posix systems too.
Jul 22 2018
Since first observing this … annoyance … the following updates have been made: Emacs has been upgraded to version 26.1, Org-Mode has been updated multiple times, including significant changes to Babel and the XHTML export, python-mode has been updated, multiple variations on the source blocks have been attempted, the document has had any and all tabs stripped out and replaced, plus each code block has been refactored and re-entered multiple times.