Sorry, I haven't waited long enough.
It's happened again. After leaving Thunderbird open for a while, when consulting another encrypted email, the window asking for the password does not appear and does nothing.
I need Gpg4Win, I'm going back to Gpg4Win 2.3.4

I think it might be a cleanup problem.
If you uninstall Gpg4Win 2.3.4, restart the computer, and then install Gpgp4Win 3.0.0, everything works correctly.

gpg-agent.conf actual content:

Does anyone of you have a gpg-agent.conf and if so, what options are set?

It works correctly when installed and executed.
After a period of inactivity and with Thunderbird still open, it stops working.
With Gpg4Win 2.3.4 it works correctly.

GnuPG is definitely not affected. I do my release test on Vista Ultimate Pro (or whatever it was called)

Someone described this issue with Windows Vista as well.

CancelIoEx is supported by Vista.

Just to inform that it is not a single problem.
I recognized exactly the same behaviour.
After terminating the gpg-agent task everything works as aspected (up to the next non-activity phase).
64-bit Windows 7 Enterprise, Outlook 2010, GPG4Win Version 3.0.0-gpg4win-3.0.0.

Please try: rA87c2bb5708ff: We can't support fd passing, if the system doesn't support it.
It disables the particular test.

I think that file descriptor passing is not supported on Cygwin.
We should disable the feature of libassuan.

No, there isn't any error message or output, and it not accept any input.
Here is a GIF capture, but may not helpful.

dirmngr is meanwhile an integral part of GnuPG. The old 1.1 dirmngr is entire obsosolete and won't do what gpg expects from it. To better diagnose the problem you can do this:

In fact, on Windows you would need to have a system service. We did this in the past for the dirmngr but remove that feature due to possible security problems and problems during installation.

That is correct, gpg-agent does not daemonize on Windows if --daemon is given, it is simply not implemented.

Without more information, we can not act on this.

Given that 2.0 reaches EOL in 6 months and the bug has been here for ages, I won't backport it to 2.0 anymore.

No I don't recall any such problems, sorry.

@werner The backport to 2.0 didn't happen, I think. Is this still relevant. @justus Do you recall any more problems in the tests?

GpgOL has even been revamped 2 times since then.

Is this still an issue?

I just released 1.7.7

werner, a quick question: what is the ETA of the new realease? I'm asking to see whether should I apply a temporary patch for the Windows64 build, or rather wait for the new release?

Thank you werner for the quick reply!

Good catch. Only on Windows64 sizeof(int)==sizeof(long) and thus the generic definition does not work.
Fixed in master and 1.7: rC7a339b1fc94cbda738cf7712830e783faa0e325e

Hi werner, I have just managed to find a solution and its really weird.
I have seen that on this platform, the mpi-asm-defs.h is being linked from the generic folder and not from the AMD64 folder. All other asm files are nicely linked fro the AMD64 folder. Here is the relevant part from the build log:

Fixed in npth 1.4.

According to @MFPA still a problem on 2.1.21.

Found the problem and fixed it. The Problem is described in the commit. Basically glib always assumed it gets UTF-8 Encoded filenames even if they were provided in system locale through double click / open with / command line / drag & drop.

GpgEX is now also compiled with ASLR + DEP. I still have to check some other binaries of Gpg4win before I close this task but I no longer see it as blocking a 3.0 release where I wanted to have this included.

Talked to Werner about this. He still has concerns that this is wrong because an application should not do globbing itself and only changing this in gpg.exe is inconsistent. It also might be a security problem as most users won't use the double dash to seperate arguments from filenames.

Added this to 3.0 because I don't want to release any known crashes.

I just commited the fix I had in gpg4win 2e71bf3. I don't see how this is objectionable as it changes the behavior back to what we had before we switched to building on jessie and is a minor ifdef.

Had same problem with waiting for .../gnupg/pubring.gpg - changed back to version 2.1.19, too [Windows 7, 32bit]

I confirmed that mingw-w64 version 1.0 defines timespec.
So, for older versions of mingw-w64, we need a fix to avoid errors.
But, your suggestion of __MINGW32__ != 1 seems wrong to me (I think it is always defined as 1).

Fixed in 6f02133bb07726afa6950e5b4685e75621276e60 by backporting a fix from
gpg-error.

After testing on Windows this problem is not resolved for Windows (I agree that
it's resolved for posix).

The issue there that I see now is not that it's a race between changing the
setting and immediately reading it again but that sometimes the communication
between gpgme and gpgconf fails.

See attached file no-read.txt for some debugging on this. GPGME writes a changed
option to gpgconf but gpgconf does not read it. I've used OutputDebugString and
DbgView to have syncronized debug output over process borders.

Not 100% reproducible but on my test system it fails very often.

Fixed in 0e242278dfaa64ce31a45b72f5fa0806a3dba898.

Actually we do not need that function on Windows. It is on Unix called at
startup to get a list of files not to close. On Windows we do not need to close
the files before a CreateProcess and thus close_all_fds is a dummy anyway.

I removed calling this function under Windows. To go into 2.1.18.

On Windows we copy the new file; on Unix we link-rename it. It might be worth
to change that old code to use estream and the same method for file updates as
we use elsewhere.

D401: 931_0001-qt-Add-test-for-CryptoConfig.patch

Can you repeat this also with GPA, which uses the gpgconf for ages?

Yes, It's even more visible in GPA because according to the gpgme log GPA does a
list options right after the change. So e.g. If you check "quiet" in the gpg
options then hit apply the check box gets unselected after apply although the
config is changed. Log is similar to the ones attached. Change options is
visible but afterwards the list-options still returns the old value.

On Linux I could not reproduce it with gpa, but as I think it's a timing issue
that might be expected. Attached is a patch that adds a Qt test which exposes
the problem on Linux. I can translate that to plain C if it helps. But I think
the attached Logs are already obvious that there is an issue.

Can you repeat this also with GPA, which uses the gpgconf for ages?

I tested with the GnuPG version 2.0.30 (GPG4WIn) as well as the current 2.1.16
Windows binaries. SCdaemon was running but was unable to get exclusive card access.
Why?
The Cisco Network Manager as well as Cisco Anyconnect VPN did both gain shared
card access (they were not told to do so!). I needed both programs to get access
to the university network.

Uninstalling both Programs and restarting did resolve the issue. To find the
two offenders I used Process Explorer (Processes for all users) and used the
Find Handle or DLL functon with the search term "SCARD". All crosschecked all
Processes (except for scdaemon which sould access the card) and Services
(svchost) to be only scdaemon aswell as the services to be Windows internal.
To determine the inital issue I used
https://sourceforge.net/projects/pcsctracker/ which told me the status of my
Yubikey (as Present,InUse -> Shared Access).

As a suggestion I like to see the experimental option to change the accessmode
from exclusive to shared on the commandline (If for example the other
application cannot be uninstalled).

Which version of GnuPG are you using? Do you have scdaemon?

In general, parallel operations aren't great, but I find that such bad
performance surprising.

If you update a key, only that key's effective policy is rechecked, not all
keys. But, the effective policy of conflicting keys is always rechecked.

While testing with tofu enabled I sometimes see that some actions take very
long. (>1minute)

Like importing a key in Kleopatra where Kleopatra does an import and starts a
keylist afterwards / in parallel.

I'll try to reproduce this on the command line. Just doing a simple import on
the command line is quick.

Do you have any hint what can take so long?
Like a trigger that would cause a rechecks for cross signatures?