I deferred this thing because I hoped to implement this in the keyboxd. Another option is to use a truncated fingerprint - for displaying purposes we anyway truncate to 25 byte and 20 byte should also be okay until we can move this to keyboxd. But okay, if you want to add support please go ahead but make sure that there are no fatal conditions if a gpg 2.2 accesses the v5 enabled trustdb.

Dear gnupg developers.
I have contacted the Microsoft to get their analysis as well.
A Case #:20812681 has been registered. Where Microsoft stated that third party developers of plugins like GpgOL have their channels and should contact Microsoft directly in cases like this. Further analysis has been denied to me.

Here is the patch for trustdb and keybox. Not introduced new record structure, but RECTYPE_TRUST_SHA2 saving only 20-byte.

Something like:

• 1-byte: TYPE
• 1-byte: Reserved
• 32-byte: fingerprint
• 1-byte; ownertrust / min_ownertrust
• 1-byte: depth
• 4-byte: validlist recnum

Any news on this?

• - it get stuck with empty window

I started "gpgconf --launch gpg-agent" and afterwards PuTTY. Then I am asked to "login as:". After entering the username, the error "PuTTY Fatal Error: No supported authentication methods available (server sent: publickey)" occurred.

Here is another thing worth reporting. I found that passphrase-repeat is entirely ignored, regardless of the value set.

Do you configured gpg so that you did not get a passphrase confirmation?

That could also be the reason for some strange behaviour I have sometimes with my bunch or readers. I have not had the time to look into this and thus opted for a gpgconf --kill scdaemon which fixes things quickly but of course this is a bad workaround.

C++ interface is also availabale in 1.14.0 (see rM690d967196d9).

I just learned that WSAStartup can be called multiple times. So, it doesn't cause any erroneous behavior which I had been afraid of.

iirc, you need to start gpg-agent before you use putty; thus do a "gpg -K" or "gpgconf --launch gpg-agent".

Thanks for looking into this. However, I do not understand the problem behind it. Is it the need to link against the socket lib? 10 or 15 years ago things were more complicated because two TCP stacks were in use and you could use the modern one only if a certain service pack or Explorer version was installed. That might be the reasons for some of the peculiarities we have in the code.

Right 2.2.21 fixes a long standing bug in symmetric encryption in that the configured passphrase constraints were not checked. Eventually we will add a second sec of constraints here but for now the same constrains as for private key protection are used.

Given the situation we have call of WSAStartup in assuan_sock_init (for Windows), the solution would be:

• Removal of call of WSAStartup in _init_common_subsystems
• Even though it is not needed for POSIX system and it is only needed to call WAStartup on Windows, calling assuan_sock_init from each application (including gpg, gpgsm, dirmngr/dirmngr-client, and tools/* which uses libassuan), would be the solution (not perfect one, though, because it allocates sock_ctx)

I am happy that your use case will be supported, and the bug was fixed before the release.
It's me who say "thank you" to you!

46d185f60 doesn't segfault and does prints the YubiKey card information, even without reader-port configured. Perfect! That will fix the issue for me. Looking forward to seeing it released. Thanks again @gniibe!

Thanks a lot.
I pushed a fix as rG46d185f60397: scd: PC/SC: Don't release the context when it's in use..

Thanks again @gniibe! In case it's still useful, I bisected to 1080e91ef. The output with --debug-all --debug-level guru is:

Ah, I identified an issue.
While it's in a loop of trying readers (in select_application in scd/app.c), it should not deallocate resources to access readers, even if reference count == 0.
I'll fix.

Thanks for your testing.

Thanks for the detailed explanation, I'm glad to hear it! Out of curiosity, I tried running echo 'serialno openpgp' | ./scd/scdaemon --log-file - -v --server built from 43000b043 and it printed:

Thanks for your report.
Major reason was multiple card readers/tokens were not supported by PC/SC handling of scdaemon, only a single reader was assumed, so, user had to specify one if it's not the first one.
Multiple reader by PC/SC support was added in master (to be 2.3), so, I think the problem is solved in master.

Sorry, I was confused by assuan_socket_ API and assuan_sock_ API.

No info received

I am not any longer interested to see the real cause; eventually we will replace it anyway with a modern CreateProcess.

Reconsidering this: Running the test suite with gpg1 is not a proper use case. gpg1 may be installed in addition to gpg but it should never be used on a build machine solely.

I don't see any error here. There is a trailing LF on the binary data which gpg rightfully complains about.

Or when there is no name the email will be taken:

As of today we don't want to maintain another binding; see T3395