Not a bug but a limitation of 2.2's option listing: In contrast to 2.3 we can't *show* the used options via gpgconf correcly if there is a conflict between global and local options. However, the actually *used* values are different and correct according to the config. In particular a global forced option overrides any local or command line option.

No, too much release work. Better just one AppImage. Or well one VSD (based on 2.2) and one regular (based on 2.3)

Not sure if we want a separate AppImage for gpg & Co. Setting priority to "Needs Triage".

@werner That is not helpful. I tried 4 or 5 different readers. And the Reiner SCT cyberjack is the one that works best.

Do not user Reiner SCT those readers are all buggy and work only on Windows - if at all. Stay away from them and get a real reader and not the incompatible broken stuff from that company. I spent way too much time trying to get those readers working. That time is better invested in support for hardware which is standard compatible or are helpful to get stuff running.

Some more info: OpenVPN does not care about the second reader. So a workaround that I just found is to disable the Virtual Smartcard reader first so that only the ReinerSCT smartcard reader with an OpenPGP V3.4 card is present. Make sure to open an SSH connection. Then reconnect the second reader. And reconnect to VPN. After the PIN for the OpenPGP V3.4 card is already cached and a connection established I can also open more SSH connections with the second reader attached and disconnect and reconnect the VPN as you want.

I am on Windows 10 21H1 and I using gnupg-w32-2.3.3_20211012 from here [1]
Together with win-gpg-agent, which extends gnupg to play nicely with Windows sockets. [2]

In T5598#151696, @aheinecke wrote:

I compiled the Appimage with the scripts in Gpg4win and it runs Kleopatra and works :-)

I compiled the Appimage with the scripts in Gpg4win and it runs Kleopatra and works :-)

Tehre has never been an option "shared-access" in GnuPG. At least not in upstream. In general we suggest the use of the interal ccid driver, but if you want PC/SC you need to use disable-ccid-driver. This is because 2.3 does not feature an automatic fallback to PC/SC anymore. Using pcsc-shared with OpenPGP cards can lead to surprising effects. You may want to try Scute as PCKSC#11 access module.

So, I have something working… in the apparent absence of any sort of clear documentation that I could find. I had some time on my hands this afternoon, so had another look.

This has not been set high on the priorities, because keyserver access works for most with Gpg4win (and thus GnuPG) on windows. A recent exception has been occurred about a month ago with Let's encrypt expired root certificate. So currently for Gpg4win 3.1.16 you need to update to a newer GnuPG (Version 2.2.32 at time of writing), by installing the simple installer,e.g. https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.32_20211006.exe

Fix for this issue landed RNP master, and will be included to the RNP v0.16.0 release.
Within fix:

• new keys will be generated with correctly tweaked bits
• using secret key with non-tweaked bits would issue a warning
• CLI command --edit-key [--check-cv25519-bits | --fix-cv25519-bits] added, allowing to fix older key

I did in fact check --status-fd before, but I'm not sure whether it gives me the information I wanted.

Please use the --status-fd interface. This yields all the info you need. An exit code is not distinct enough for such purpose and you need to check the status lines in any case. For scripting gpgme-tool or gpgme-json might be useful as well because they do all the nitty-gritty parts of using gpg correctly

Argh, sorry for bugging. Clearing comment out - I simply missed fact that my tests are run with random messages, so with 5% probability another password will be interpreted as 'good' for the first SKESK.

In my understanding, it should be possible to wait for the gpg command pipe from a different process and then terminate the connection on a timeout, kllling the process eventually. So the Enigmail side could implement something. These days I'm not sure what Enigmail uses for OpenPGP support. Thunderbird has moved on to a different implementation and Enigmail stops supporting Thunderbird 68 in two days https://www.enigmail.net/index.php/en/home/news/71-2021-08-31-end-of-support-for-thunderbird

Well, as I've said in the comment above, there doesn't seem to be any correction towarads --passphrase-fd not requiring --pinentry-mode loopback (still works withou)... and --no-default-keyring still gives the impression that it would be needed (while --no-keyring works as well).

Please don't, if you really feel like tha tis not resolved please re-open this ticket.

@werner shall I open a new ticket for the remaining stuff?

Works if one puts

rootdir = $APPDIR/usr

in the gpgconf.ctl file.

I'm not really sure which version it worked with earlier. This yubikey setup is quite old now, and I've not signed keys recently. I think the last I signed were at least 2 yrs back, hence the very vague allusion to the setup working previously. Apologies, no definite answer there.

1. >>gpg2 --version

gpg (GnuPG) 2.0.30 (Gpg4win 2.3.3)
libgcrypt 1.6.6

@amit: Do you say it used to work with GnuPG 2.2.27 or did it worked with an older version?

Which gpg version?
Which Python library? (gnupg is pretty generic)
How does the Python library call gpg?
Are you aware that gpg uses utf8 and not Windows Unicode?

When you sign data, then the signing subkey is used

ssb>  rsa4096/0xEB0B4DFC657EF670 2016-04-01 [S]

Just noting that the logs were captured by enabling debug logs for the agent:

eval $(gpg-agent --daemon --debug-all --log-file /var/tmp/gpgagent.log)

Thanks for clarification, indeed attempt to decrypt data returns an error afterwards.

Well, while importing you get the warning:

Yes, for migration from GnuPG 2.0 reasons, a batch import delays the key checking (i.e. converting from OpenPGP to GnuPG internal format) to the first use. Thus you don't see an error immediately. But if you encrypt something , you won't be able to decrypt it again:

Thanks, Werner.
During further work on this got another issue:

The actual patch is rGd4768bb982adb5c8410303334ee8d82ba0d71f3b (our parser in dev.gnupg.org missed to pick up the bug-id due to teh use of scissor lines in the commit message).

The changes do not seem to touch anything I've mentoned in (1)?

I see, I wasn't aware of this. Thanks for fixing!

Thanks for commenting. I close this bug then.

Your proposed fix (in your first comment) has actually already been applied (commit 1305baf0994059f458b1d5ca28a355c12932fab3 in master, backported to the -2.2 branch in 455ba49071dea7588c9de11785b3092e45e4560b). It is part of gnupg-2.2.31 released today. :)

The Qt upstream bug report has just been rejected. I hope something can be done here...