Applied to 2.2 branch.

As written in T2438:

I think that this is same issue of T2438: dirmngr fails repeatedly with "invalid argument", without kicking the host from its list.
Merging.

For the problem in the last comment, it was fixed in T2928: stop fetching PTR records entirely.
For the original issue, it looks that EINVAL is returned by the system call of connect(2).
That's quite strange, but, it was possible for IPv6.

Good. I don't think there is any reason to select the ephemeral port in user space (by default).
So, I disabled the feature for all OSes.

Hi Werner,
I have performed some experiments on the issue I have and the following are the results:

Do we have an update on this? I seem to be having similar issue. Cannot import a key from my old gpg 1.x version to gpg 2.x version

could i get feedback on this ticket? a simple, clean patch is available, and i don't understand what is blocking it.

@gniibe Thank you very much!
I've tested the change on Windows 7 and Windows 10 and the Firewall warning is indeed gone with this.

I found dirmngr tries to bind some random port. It might be the cause.

As expected it was a very clear bug. We assign a NULL pointer to a string and then use that string.

Thank you for the report and the logs! A minor note: For future reports please leave the priority on "Needs Triage" we use this as a marker for issues no developer has looked at previously.

To avoid releasing incomplete tarballs this release should also be built from the source package and no longer from the git tag.

Fixed in repo (master and 1.8 branch).

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.