- User Since
- Mar 27 2017, 4:48 PM (200 w, 1 d)
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.
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.
Mar 3 2019
GPGME 1.12.1-beta43 is nowhere near the current master. Current is around 1.12.1-beta130 (or above) and beta 43 would've been months ago, probably early November or late October.
Feb 11 2019
Feb 10 2019
Jan 30 2019
Jan 27 2019
Jan 14 2019
Jan 13 2019
Jan 2 2019
Dec 26 2018
Dec 21 2018
What are MS doing when they get it right, though? I'd look at the differences between those two to identify what they've messed up here.
Dec 17 2018
Dec 16 2018
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 13 2018
Dec 12 2018
Dec 10 2018
Though apparently resolved back in May, this is what ultimately led to T4191 and was thus only properly resolved quite recently.
See T3505 for more in depth coverage of this issue. Essentially this is a duplicate under a slightly altered POV.
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
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.
Dec 4 2018
Nov 30 2018
Nov 26 2018
Nov 22 2018
Nov 19 2018
This should be fixed in commit fd34415bdd57332424bd5a98d279e2331678a2fb
Nov 6 2018
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 30 2018
Oct 23 2018
Oct 21 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.
Oct 4 2018
Oct 3 2018
Oct 2 2018
Sep 30 2018
Sep 27 2018
Sep 26 2018
In the interests of completeness I also tried it on a much larger file (1GB) which was both signed and encrypted. I also set the decryption to show the session key just to confirm it was decrypting since the plaintext was being sent to /dev/null.
I am unable to replicate this on OS X 10.9 Mavericks.