Closing since the cause for this was identified.

I assume the problem has been resolved because we never got feedback that the problem persists.

Fixed in master: rGe7891225788a: gpg: Robust error handling for SCD READKEY.

Some would say it is a bug if keys are not shown - even if the algo is not known ;-)

scdaemon in this case was a broken experiment of mine (trying to see if I can get SoftHSM to work as the OpenPGP card). So this was not a normal, released scdaemon code.

I can replicate the problem.

What is your usecase of doing a thousand secret key operations (signing) on apparently extremely small data files a minute

by default we keep the unlocked secret key limited to this very tiny process (gpg-agent) which only does the secret key operations. That is I think the best decision. It is IMO not really a bottleneck since except for very small data bits the bottleneck is usually the hashing. What is your usecase of doing a thousand secret key operations (signing) on apparently extremely small data files a minute? And even then are you sure it is not your disk IO that is the bottleneck and it is in fact gpg-agent?

Why couldn't gpg-agent just fake these homedirs on its own?

Well this depends of course. If the "Hard work" is the actual signing it depends a ton on your Key. An ECC key will go much quicker then for example RSA4096 but IMO the "Hard work" when signing is the hashing and that is done in parralel for extremely specialized setups you could run multiple gpg-agents in different homedirs with access to the same key.

I create 1000 empty files, and sign then using GNU parallel+gpg and trying various parallelization factors. (CPU used is AMD 3700X with 16 threads.)

closing, as setting a password on a key without password works (at least in current gpg4win version). For improvement of the user guidance see T6436.

Hello Andre Heinecke,

Hello Andre Heinecke,

Thanks for the certificate, looks good as far as I can tell. I have trouble with CRL checks for your certificate as https://crl.sectigo.com/ does not work for me. But that should not be an issue when decrypting.

Hello Andre Heinecke,

Please attach the certificate so that we can check what is problematic with that certificate. I am changing this issue to wishlist as the solution here will most likely be that we have to extend the S/MIME capabilities of Gpg4win.

@aheinecke What additional information do you need ?

On the command line using:
gpg -o output.txt --decrypt "yourfile.asc"

There must be something special with the message. Can you save the message to a file and use the command line to decrypt it? Is there anything special with it? Is it maybe a binary and not text? Although I tried decrypting random bytes with the notepad and it worked for me. Is the message very large? Anything unusual? Or does it even happen for you when you encrypt a short text to yourself and then decrypt it again?

If we would provide Gpg4win-3.1.24 also in binary form we would make it harder for us to argue that VS-NfD users have to purchase GnuPG VS-Desktop with the required support

For Gpg4win we will soon release a 4.0.4 Version that will contain the latest Kleopatra updates and GnuPG 2.3.x, but the 3.1.x series of Gpg4win is something that we only release in binary form as part of our Product GnuPG VS-Desktop.
The reason for this is that for VS-NfD there are some responsibilities for the supplier, and so the VS-NfD user needs a responsible supplier. We do not promise that for Gpg4win, which is the free community version anyone can download. If we would provide Gpg4win-3.1.24 also in binary form we would make it harder for us to argue that VS-NfD users have to purchase GnuPG VS-Desktop with the required support.

GnuPG requires threads but not gpgme.
We already had the same discussion about threads and libgpg-error more than one year ago: https://dev.gnupg.org/T5296

Thank you for your report. Next time, please include information of your target and configuration in the report.

This looks like a different but not too uncommon problem. For T6169 we need to get a PKCS#12 file to be able to replicate the problems - obviously that PKCS#12 should hold only test keys/certs.

Still, the first thing you should do is to update to a recent version, the version you are on is about 3 years old. See https://gpg4win.org for the most recent version. Then add --verbose and --debug ipc to your command so we can maybe see more what it does.

I tried to reproduce this as we had similar problems in the past, but for me this works with full unicode characters.

as of 2.3.7 (which I just updated to) this works. ticket can be closed

Please give us more information.

• Do you change SSH program?
  • If so, please check if adding configuration https://dev.gnupg.org/T5935#157674 for ssh works.
• Do you mean, reinstalling gpg 2.3.4 fixes your issue?
• Are you using with smartcard/token? Which one (Yubikey/Zeitcontrol/Gnuk), if it's the case?

Reading through the report, the spec., and current implementation, I concluded that this is not a bug, thus, I'm closing this.

@werner For what it's worth, I would like to apologize for my rudeness and disrespect. I had a quite convoluted notion of what the development process entailed. In particular, I was ignorant of the different and opposing responsibilities and the separation of concerns involved in the development process. In retrospect, there were at least a dozen different ways in which this could/should have been handled and all of them are downstream.

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.

Problem/Bug still persists in current version (gpg4win 3.1.16) --> reopen

Thanks for the log, however, I would suggest to use 3.1.16 and try again.

Sure.

And it shows

Thank you so much for your explanation.
I just want to try with older version. Because when I try to run