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"

I made it optional for now with default on. So that if it crashes it can be disabled. We need to see if the crash is a general problem or a special problem of that one tester.

This was fixed with kleo rev 289efa360f6b15a3389ea2f2efede352711e7d7e

We disabled the codepath that required this for now. Lets see how it works.

I can't reproduce this. When I make Dirmngr offline I correctly get a No CRL known error. So it must be something different.