npth_t is untouched for Windows 64-bit.

assuan_sock_accept approach is taken in gnupg master.

gniibe/t6606 patches are all pushed into master.

Applied: rGb8c5d99406c9: gpg,agent,kbx,sm,scd,tpm2d,g13: Use assuan_control.

In T6606#173044, @gniibe wrote:

More care is needed to be perfect; There are places in GnuPG where assuan_sock_connect may be used before syscall clamp set up (after the first assuan_sock_bind failure).

Applied to master.

Applied the changes for libassuan T6487 into gniibe/t6606.

Pushed the change in gniibe/t6606 branch.

Another approach would be:

• Use assuan_sock_accept which has consistent API with gnupg_fd_t

On 64-bit Windows, the situation now is:

Use of FD2INT for the first argument of select is semantically not good. It's the number of file descriptor. When we use FD2INT here, the type is converted to 64-bit integer, then implicitly demoted to 32-bit integer. We need new macro, say, FD2NUM to convert FD into 32-bit integer.
<--- done in: rGea1935252e28: commond: Introduce FD2NUM to express conversion to number of fds.

Here is a test program for 64-bit Windows to see how cast works:

#include <stdint.h>
#include <stdio.h>

The case in check_special_filename is fixed. So, there is no cases in GnuPG where the value of out of range is silently converted to wrong value.

Remaining places are:

• common/sysutil.c debug output to format HANDLE --> T6597
• common/sysutil.c iobuf_get_fd and its use cases --> T6580
• agent, kbx, scdaemon, dirmngr: socket and FD2INT/INT2FD --> T6598

Except a case, all use cases of translate_sys2libc_fd_int is with a result of integer from command line argument.

Changes are pushed.

We need to keep the gpgtar part of commit in rG2756147e392c: gpg,sm,tools: Use string for option --*-fd..

The changes are intrusive to other implementations (POSIX and Windows 32-bit).
So, I revert the changes of replacing translate_sys2libc_fd_int.

I don't argue about the technical necessity for the change. I agree the fact it works (without such changes).

Just to clarify this change for readers not accustomed to Windows internals: This function was used to translate the file descriptor as passed to gpg (which is a HANDLE) to the libc file descriptor as used by stdio. Obviously we won't anymore work with stdio file descriptors in the future but use the Windows32 API (ReadFile et al). libc fds 0,1,2 are handled in a special way on Windows.

Fixed in master.

The use cases are:

• oPassphraseFD for gpgsm, gpg
• oStatusFD for gpg-auth, gpg-wks-client, gpg-card, gpg-pair-tool, gpgtar, gpgconf, gpgsm, gpg, gpgv
• oLoggerFD for gpgsm, gpg, gpgv
• oAttributeFD for gpg
• oCommandFD for gpg
• oOverrideSessionKeyFD for gpg

to give you any help I would need to know the exact error. I can only tell you that this is not a problem related to Gpg4win something else must be messy on your system. The Uninstaller of Gpg4win cleans up all registry keys that do not contain user config and all files should be removed unless some other process on the system interferes.

Added variable value

set language
LANGUAGE=en_US

I launched the Kleopatra again. I did not notice any changes.

Thanks for your report. Yes this is sadly a known issue. Our backend system has it's own localization that uses the system language and does not care about the Kleopatra configuration.

I realized that suspend/resume is not supported yet on GNU/Linux: https://anonscm.debian.org/cgit/pcsclite/PCSC.git/tree/TODO#n7
So, I can't test myself.
Here is an attempt to improve:

It looks like SCardGetStatusChange doesn't return failure after wake up.
Here, what we need is catching the event of wake up, which requires reset of the card.
I think that we can check by the dwEventState field.
I'll try on GNU/Linux environment, then ask you to try.

@werner there had to be some mix up, as the log snippet is not mine.

This seems to be the relevant part of the log:

2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card inactive/removed
2017-11-18 07:45:15 scdaemon[8918] ccid open error: skip
2017-11-18 07:45:15 scdaemon[8918] pcsc_establish_context failed: no service (0x8010001d)
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: interrupt callback 0
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card removed

Tested with Gpg4win-3.0.0-beta17 with GpgOL-2.0.2-beta8 on Windows 10 (64bit) with Outlook 2016.

Jochen could you please test this on one of our test VM's again and resolve this then?

I am closing this bug report, as I can't get feedback to fix something.

gniibe: Can you check the status?

Please try this patch:

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.

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?

I've just announced a new 3.0 beta that contains the updated GpgOL

http://lists.wald.intevation.org/pipermail/gpg4win-devel/2016-November/001659.html

Please let me know if it still crashes for you with that version.