Thanks for your report.
You are right.
Simply getting the information for "rng-type" through gcry_rndjent_get_version will hang.

My bad this already exists.

Investigated the "why not with glibc" question this morning, appears that the test triggering the hanging behavior (version) happens to not be linked with -pthread and so locking calls do nothing. Manually adding -pthread causes it to hang with glibc as well.

See also: https://github.com/NixOS/nixpkgs/pull/42150

Thanks for forwarding.

On 06/17/2018 02:10 AM, BenM (Ben McGinnes) wrote:

The two subsequent commits are the one I mentioned above (nested try/except
statements) and followed by a major PEP8 compliance overhaul of core.py.

Thanks for the patch and welcome to the weird and wonderful world of FOSS. :)

I'm seeing this as resolved. It's a design decision by the pinentry-gtk maintainer. pinentry-qt is the default pinentry for windows and there pasting works, as you have confirmed.

We did not have more reports about this so I'm resolving it here.

This is still true even after the latest changes to GpgOL not to require Kleopatra or GPA through the UIServer protocol. The details dialog / search still uses Kleopatra or GPA as a fallback.

I'm closing this as a duplicate of T3459

Two more reports in the Gpg4win forums. Still can't reproduce it. I've asked for debug output.

I'm closing this as duplicate of T3459

Has long been in testing. I think it is improved now and CRL's also work.

The fix for this was released with Gpg4win-3.1.1. Forgot to update this task.

I will try to figure out what exactly triggers the firewall. This should really be fixed as it leads to a bad "first contact" with Gpg4win, especially as we do more locate-keys nowadays so the question pops up randomly for the user.

I'm changing this to wishlist as I don't think anymore that we have something new here. When working with unsigned files the user has/had already the same problems as described in the issue.
(Wishlist does not mean that it will be ignored.)

The change was released with Gpg4win-3.1.2

The changes were released with Gpg4win-3.1.2.

Gpg4win-3.1.2 was released yesterday.

Forgot to comment. Yes what is in the video is also what I thought.

Fix is released in Gpg4win-3.1.2

Fix is released in Gpg4win-3.1.2

And 2.2 branch.

The problem is complicated because we would have to parse each multipart/mixed mail before we can know that the mime structure looks that way.

Fixed in master.

It's in 2.2.4 and 1.4.23.
Closing.

Support was removed.

Patch committed to master in commit 5a80e755008bbb3f4c7f91ffccd38f26cd8b3960

Not to worry, we've all been pretty busy of late.

I re-tested this with version 2.2.8 and the same result.

I'll fix for the non-FQDN case.

I think that I identified the issue. This is the libdns (dirmngr/dns.c) problem when hostname is not FQDN.
If you change it to FQDN, you can see that it tries to search adding the domain name.

This was released with Gpg4win-3.1.1

For issues/19, it is also reported in T3374: gpg recv-keys fail if first dns server end up with "Connection refused".
This is fixed in master now.
I'm not sure if original reporter's problem is issues/19 or not.

Fixed in master.

It is indirectly reported at the upstream: https://github.com/wahern/dns/issues/19