Thanks a lot.

Fix will be in 2.2.22. Thanks for the report.

It was actually moved to noninstall in 2006. The reason or this is a conflict between the version of gpgsplit in GnuPG 1.4 and 2.0. Back then it seemed easier to keep on using the gpgpslit from 1.4 because that version was installed anyway. At that time gpg was called gpg2 we changed this much later and probably forgot to switch also to the gpgsplit from GnuPG 2.

You used --personal-digest-preferences to force the use of SHA-512, right?

Do you mean you want to copy a backup key created while generating the keys for the card onto a new card?

The problem appears to be the test framework is not setting a LD_LIBRARY_PATH (or DYNLD_LIBRARY_PATH on OS X).

As far as I know, the environment is set correctly. PKG_CONFIG_PATH, --prefix and --libdir are set. And runpaths are also set.

I meant:

If you can point me to a commit, I can patch the package and retest it.

If there is no other problem (than the issues of additional slash and double slash), I'll close this bug report.

Solved in master (1.9). We won't do it in 1.8.

Use

gpgconf --kill dirmngr

to stop it.

Thank you, Andre. Just updated here, problem fixed.

Thanks Andre,

This has been shipped with Gpg4win-3.1.12

I don't mind if this is marked as resolved. As long as I use my script, the agent works flawlessly with my Nitrokey. The agent startup is very fast. The script also resolves the effect that the agent won't work after the system is waked from sleeping state.

Thanks for providing your workaround.

I'm not sure what to do with the issue. For further analysis we would need to figure out what third party software breaks the MIME structure of the mail. That is more something for a support contract and not for the general issue tracker. This issue is very specific to your setup and so I'm not surprised that Microsoft says it can't help.

We have released 3.1.12 which updated all the GUI libraries Kleopatra uses and I got some feedback in related issues like T4689 that this might have helped.

3.1.12 was released with this.

I just ran the test suite ~10 Times with -j48 on a 12 core machine and cannot reproduce this at all with GnuPG-2.2.21 and gpgme-1.14.0 so I tend to put this on resolved, otherwise this is a candidate for an issue that will be indefinetly in the tracker which we cannot reproduce or analyze further.

The t-json failure is: T4820

Thanks, I've applied this with an explicit include to <cstdlib> it was not required on Linux and Windows but I think it's better not to rely on internal libc++ include chains.

@bzbue1 Thanks for the info.

I'm afraid that the dynamic linker doesn't allow hardcoding library path in an executable on macOS.
(It is only supported on some limited platforms.)

I can no longer reproduce this in Gpg4win-3.1.12.

Thanks for your report.

According to OS X 10.9 man pages for getenv(3) (10.9 is what I have available), the source file editinteractor.cpp should include <stdlib.h>. Since its a c++ source file, I believe the include of interest is <cstdlib>. The man page also says the link library is -lc.

BTW, I learned that Fedora now uses pkgconfig (instead of pkg-config).
https://github.com/pkgconf/pkgconf

Try with --prefix=/home/jwalton/tmp/pk2delete (with no slash at the end) and --libdir=/home/jwalton/tmp/pk2delete/lib64 (with no double slash between pk2delete and lib64, but a single slash).

There are no log file but you can run the test by hand:

I realized that it fails with GPG_ERR_INV_ID (with gpg master) when it's on smartcard.
It can't be decrypted if it's on smartcard, that's true, but more relevant error would be good for this case.

Something looks odd about the way I pasted that key in there. The last 4 characters are bold, and it is missing an = sign.

I just saw that there is related discussion and a patch for this in T4994 so I will close again here.

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.

This change broke for me the compilation of GPGME which I fixed with: 52f930c1ed7eee6336a41598c90ef3605b7ed02b I found that fix there OK because GPGME explicitly uses ws2_32.

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.

• - 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.

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

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.

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.

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.

No info received in3 years.

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.

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

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.

A reference might help:
https://blogs.itemis.com/en/openpgp-on-the-job-part-8-ssh-with-openpgp-and-yubikey

I have also relaxed the test in gpgme for that GnuPG version.