Not for export, there's a few traps in there, but if you want to take a second swing at import, I'd probably accept that instead.

Okay, the import is pretty much a match for what I have tucked away elsewhere, to that will probably get merged as is, more or less.

Actually op_import and op_export do work, but they're the underlying SWIG bindings, not the more pythonic layer Justus added a couple of years ago. I'd been planning on fixing that this month (part of the work is in one of the ben/howto-update branches), but not merged with master until it could be documented since there's something potentially hazardous in there (exporting secret keys).

It works (or rather fails to decrypt) as expected, though an update to the HOWTO and examples is also needed, not a major change.

Since 1.4 has been previously cited as the thing to use when accessing data encrypted with v2 keys and the like, it's hard to argue in favour of backporting a fix for an issue which will explicitly override the one major use case (maybe one of two if we count headless systems still) for keeping 1.4 in play. If you were going to fix it and and potentially kill the use of it for accessing old archived data then why not just skip the backport and EOL the branch? Less work, same result.

Webhelp version of the Python bindings HOWTO is currently available here:

As a work-around for this bug I've ported the HOWTO from org-mode to DITA XML and will generate a webhelp-responsive (i.e. searchable) version to put on another website (an Amazon S3 bucket since it will be reliable and cheap) in the interim.

Org-Mode was updated to today's release and further testing was conducted.

I suspect gpg4usb is a dead project anyway. I've been on their mailing list for a while and according to my records the last post from the pseudonymous author(s) is from October, 2016. I'm not sure how much of that GPL breach is intentional or just a result of web services going offline and not being restored.

The Python portion of this is done, the tests will now create a key with an expiration a few years shy of the 2106 end date (NYE 2099).

I've just checked the current build to the previous one (even when I get rid of the build directories, I keep a copy of the config.log since you never know when it might come in handy).

FYI: this most recent update broke builds on OS X 10.9 for Qt, but everything else is fine.

Clearly getting SWIG and Windows to play together nicely is a bit of a big ask, but it may be possible to leverage GPGME's compiled libraries with something like CFFI's ABI calling method (yeah, I know, ABI is never ideal, but it's better than what Windows has now).

The last change to the python installer was, IIRC, one I discussed with Justus off-list around the middle of, um, last year? Maybe the year before?

Not to mention making sure we test for a time after the end of the old 32-bit clock.

In T3751#110422, @cipherpunks wrote:

What's in daily use for 15 yrs? GPGME? I thought GPGME was new,

Since the initial redacted data for those four keys is still accessible, I checked all of those keys manually and none of them are on the keyservers. Since the OP was connecting to the specified keyserver successfully prior to that failure, I believe this is the cause of the error and not another DNS vs. Dirmngr conflict.

This may be related to T3515: Gpg4win: Gpgconf used to open "windows" and slows down kleo startup since it depends on data from gpgconf.

A work-around is now available for this in Python in the GPGME source. The relative path from the top of the GPGME source directory is here lang/python/examples/howto/groups.py. Like all the other scripts in the same directory, it also appears in the GPGME Python Bindings HOWTO, under the Miscellaneous heading near the end.

This does not require org-feed.el as far as I can tell, but it does require components of current Org Mode HTML export and publishing features which do not appear to be available in the current gnupg.org website build system.

A more recent request for this feature has been made via the devel mailing list: