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

The Python bindings are troublesome enough; as of today we don't want to maintain a Perl module.

No info received in3 years.

Has already been fixed with T4061.

C part done; C++ interface is not yet done.

Hi, yeah its complicated for Kleopatra to detect the defaults as they can be set both in Kleopatra config and GnuPG config. The GnuPG config overrides the Kleopatra config. Kleo has code to handle this but not when it adds the comboboxes to the GUI. So I've just removed the "default". We only had this for RSA and DSA / Elgamal, for ECC we did not indicate the default.

Well, it changes the behaviour on error and thus it should not be backported to 2.2 so that existsing error reports about corrupted data don't change. Fine for master.

Here are the fixes:

diff --git a/common/init.c b/common/init.c
index 073c5cd8a..dbdf40527 100644
--- a/common/init.c
+++ b/common/init.c
@@ -161,17 +161,6 @@ _init_common_subsystems (gpg_err_source_t errsource, int *argcp, char ***argvp)
   /* Try to auto set the character set.  */
   set_native_charset (NULL);

Call of WSAStartup in dirmngr/http.c is no problem, as we define HTTP_NO_WSASTARTUP.

This fix reveals the problem of: T4994: Windows: assuan_sock_init or WSAStartup by main/_init_common_subsystem

Today when I've been trying with -j48 test suite was locked and was not able to finish.
When I've presses ctrol-c I found:

PASS: t-eventloop
Decrypt B 0
Encrypt A 0
Decrypt B 1
Encrypt A 1
Decrypt B 2
Encrypt A 2
Decrypt B 3
Encrypt A 3
Decrypt B 4
Decrypt B 5
Encrypt A 4
Decrypt B 6
Encrypt A 5
Decrypt B 7
Encrypt A 6
Decrypt B 8
Encrypt A 7
Decrypt B 9
Encrypt A 8
Decrypt B 10
Encrypt A 9
Decrypt B 11
Encrypt A 10
Decrypt B 12
Encrypt A 11
Decrypt B 13
Encrypt A 12
Decrypt B 14
Encrypt A 13
Decrypt B 15
Encrypt A 14
Decrypt B 16
Decrypt B 17
Encrypt A 15
Decrypt B 18
Encrypt A 16
Decrypt B 19
Encrypt A 17
Encrypt A 18
Encrypt A 19
PASS: t-thread1
make[4]: *** [Makefile:882: check-TESTS] Interrupt
make[4]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/gpgme-1.13.1/tests/gpg'
[tkloczko@barrel SPECS]$ make[3]: *** [Makefile:1008: check-am] Interrupt
make[2]: *** [Makefile:1010: check] Interrupt
make[1]: *** [Makefile:736: check-recursive] Interrupt
make: *** [Makefile:535: check-recursive] Interrupt
^C

It might be related to T4257 - try with -j4 for now which is what I use for building.
For further investigations we need to enable tracing using

GPGME_DEBUG=8:gpgme.trc  make check

In T4854#135871, @werner wrote:

Sorry, I can't replicate this

Probably the same as T4257

We can't do anything about it except for corner cases which we won't do right now. In case there will be an easy solution to help Debian please re-open this bug.

Sorry, I can't replicate this

From 1.14.0 on these functions will return a Not Implemented error and the documentation has been removed.

I used already the mentioned blog ass base of my work. But the Yubikey is not recognized in ssh and I do not know how to mitigate.

Its a year since I worked on the mentioned wait code change (wk/new-wait branch) and I more or less forgot about it. it will to risky to release that as 1.14 so this change and the fix to this bug needs to be postponed to 1.15. Sorry.