Glad to hear. I've also now had time to manually apply the patches and have not seen any issues so far! Thank you! If anything does turn up later down the road I'll let you know.

No, no apologize needed. You did your best for the bug report, and it helped us a lot to identify the issue, and it certainly helped resulting the fixes. Moreover, your report kicked another fix of T5979 (thanks to the valgrind output).
Thank you.

I apologize, you seem to be right. Even though the package build log shows that all patches were applied, it seems there are some hunks missing in the generated sources.
I've attached my patches, but those are most likely correct. There seems to be an issue with my distribution's package manager. I will investigate this and report back afterwards. Maybe I'll just build it manually.

When compiling the package, I can see that all 4 are applied.

I think that it means that you only applied the last two patches.

Thanks again for your update.

Thanks a lot for your cooperation.

I put more fix for error handling of key algorithm attribute.
The change: rG53eddf9b9ea0: scd: Fail when no good algorithm attribute.

Thanks a lot for your cooperation.

Contrary to your expectations, all gpg --card-status fail after yubikey insertion:

Please do experiment again and give us the whole log of scdaemon.log for:

• insert Yubikey initially
• run gpg --card-status (success is expected)
• remove Yubikey
• insert Yubikey second time
• run gpg --card-status (failure is expected)

In case you need any information, be sure to let me know. Maybe we can add some manual loggers to the patches, to confirm that everything is working as you imagine it to?

Umm... The problem is the last bogus octet from Yubikey. In the log, we see:

I'm certain I've applied the patches correctly. This is my current patchset:

Thank you for the logs. It seems that scdaemon didn't detect the removal correctly.

I've uploaded the requested information with triple verbose and debug-all setting in the scdaemon.conf as scdaemon.log:

I examined all log files you gave us, and I think that scdaemon with PC/SC fails to detect the removal of the USB device.

I've applied the linked patch, but still experience the error. Most of the times, I cannot access my yubikey at all and I am not sure what is blocking it.
I've tried to include as much debugging output as I could below. Please let me know if there is anything else I can do to debug this.

The patch rG054d14887ef8: scd: Add workaround for ECC attribute on Yubikey. fixes a particular problem of Yubikey implementation where it returns bogus octet for its data object of C1, C2, and C3.

The issues mentioned in the previous comment have been fixed.

I had a look at the file system watcher we use to react on changes in the GnuPG home directory. It doesn't watch the private keys living in private-keys-v1.d. Moreover, it does not handle the removal of files properly.

When we will find reproducible test case, please reopen.

Thank you.

{F3381469}I uploaded the whole homedir containing the keys after they were migrated by the new gnupg2.3.4. It should have all of the keys in there. Don't worry, these keys are just for testing and not used anywhere.

Oh, I' sorry - my fault. I searched in ...\GnuPG\bin instead of ...\gpg4win\bin

I have just checked both the installation script, which still installs gpgme-json.exe and the gpg4win-4 installer downloaded from gpg4win.org gpgme-json.exe is properly installed under <instdir>\bin gpgme-json.exe and under bin_64

Hi guys, I just tested the git version (426d82fcf1c133bfc1d5c931109d71db3f3815a9) and it works well thank you.

Fixed in 2.2.33.

Sure there are logs, see the options log-file and debug in the man pages.
To sign using specific subkey or the main key, use the fingerprint of the key and append an exclamation mark.
For example

I think that this is due to support of UTF-8 codepage problem by console.

Hello Mr. Koch,

@Reiner: Any news; were you able to run the the command with redirection to some file?

Lets downgrade the priority and keep it open in case we get reports from customers. The other option would be to replicate this here using our AD demo network. But that is a bit time consuming.

I tried to reproduce this. Experimentally, I added P15CardWidget::searchPGPFpr() to OpenPGPKeyCardWidget, commented out the code that checks for an LDAP keyserver and called the function with a fixed fingerprint.

I don't know if it's same in your case, but to fix my case, I pushed a change rG48359c723206: dns: Make reading resolv.conf more robust.

I managed to create a case. Put a line:

BTW, in your screen shot (log is preferred here), it shows 1c00, that must be actually written as AAAA (0x1c). In the bug T3803, we saw byte sequence like that, additional 00 was added then resulted malformed DNS packet.

dots are not allowed in hostnames.

OK, I'll gdb in there to see what happens. My domain is a classic pgp.domain.com

Ah, other possible case is .. in hostname.