With certified keys the automation is working as expected.

Got a new OL 2013 test setup where this was finally reproducible for me.

OK, I take this ticket.

Discussion on the #python IRC channel last night with another experienced SWIG developer (of a proprietary and unnamed software project) has provided ass itional evidence supporting the theory that the cause of the problems with getting the bindings to run on Windows systems is indeed directly caused by the fact that Windows users are compiling GPGME and the bindings with a different compiler and runtime than those used to compile whichever version of Python they have obtained from elsewhere.

Well, I have already tried to explain the use case: To make using cryptography easier for our users (for most of them the command line is the hell ...) I have integrated GnuPG in our webmailer. The webmailer has a key management page where you can import and export keys (up- and download, import from mail, attach to mail etc.), where you can edit trust settings, and where you can sign other keys and revoke such signatures. The webmailer certainly does not offer all capabilities of GnuPG but certainly a substantial subset.

The option you mean is "Disable non-blocking encrypt / sign", correct?
It's english in the german dialogue, btw.

Thanks for the tests and the report.

This seems very special and I'm not sure if we should not say at some point that we won't add quick commands for everything ;-)

The crash on send should be avoidable by checking "Disable async encryption" in the options.
Yesterday I got a new OL 2013 test system with which I can reproduce the crash. So that will be fixed or worked around for the next release.

no. Outlook 2013 reproducably crashes on sending and won't toggle
encryption on.

Ok i saw they apply custom patches to _gpgme_mkstemp which are outdated and should be revisited, sorry for the noise

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

ping, what's the status of this bug? it has been in testing for over one year. is that the correct status?

Sure, this should work, local keys are preferred.

But can't I simply use the keys in my local keyring?

No you can not use an "external" Web Key Directory. The point is that the provider (your domain) should be the source of the keys as it already manages the mail account. ( For more info see: https://wiki.gnupg.org/WKD )

Thanks for the report. I've commited a fix. (Returning the c_str here is ok as the data is not meant to be modified once "action" is called)
Please let us know if you find additional issues.

I downloaded GPGwin v3.1.3 beta 20 today. The automatic key fetching fails in my case because we have no WKS. Never heard of that before.

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

There is the same bug and fix in function parse_key :

diff --git a/g10/parse-packet.c b/g10/parse-packet.c
index 0d28e7ac1..b147179e2 100644
--- a/g10/parse-packet.c
+++ b/g10/parse-packet.c
@@ -2533,7 +2533,7 @@ parse_key (IOBUF inp, int pkttype, unsigned long pktlen,
                      err = gpg_error (GPG_ERR_INV_PACKET);
                      goto leave;
                    }
-                 ski->s2k.count = iobuf_get (inp);
+                 ski->s2k.count = iobuf_get_noeof (inp);
                  pktlen--;
                  if (list_mode)
                    es_fprintf (listfp, "\tprotect count: %lu (%lu)\n",

I misunderstood your original report.

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.

Was anyone successful in debugging dirmngr? I'm having the same issue. The dirmngr process gets stuck, no output at all, and this causes Kleopatra to get stuck waiting for it. I can only run Kleopatra after I have killed the dirmngr process. If I understand correctly I still need this process for network-related functionality, so I would need to fix it if I want to use all functions.

I updated the software to its latest version "gpg4win v3.1.1" and i'm still facing this issue.

Patch applied. Thanks.

I think that the ultimate decision here lies with Werner. Additional review.
I think the biggest obstacle is that we don't want to change the random gathering code if it can be avoided and that the random code has been thoroughly reviewed / tested and is currently considered secure.

I do not see the harm in this patch and it seems useful. Indeed it seems better then making a directory in tmp as this might create regressions for others.

This bug report has been around for several months now. it has a simple patch, a clear explanation, a report of running code, and examples of problems it solves.

Good to know, no problem, just wanted to document it just in case they do remove the API entirely in the future.

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.

Indeed. Thanks for the reminder.
There is some code currently in there already but its not yet fully implemented. Needs to be finished.

Deleting a user id is more or less useless. What you want is to revoke a user id.

In the current gpg4win-3.1.3 beta 20 this is enabled again. It can be disabled in the options with "Disable non-blocking encrypt / sign"