Thu, Nov 25
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.
Tue, Nov 23
No, too much release work. Better just one AppImage. Or well one VSD (based on 2.2) and one regular (based on 2.3)
Mon, Nov 22
Not sure if we want a separate AppImage for gpg & Co. Setting priority to "Needs Triage".
Wed, Nov 17
@werner That is not helpful. I tried 4 or 5 different readers. And the Reiner SCT cyberjack is the one that works best.
Sat, Nov 13
Fri, Nov 12
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 
Together with win-gpg-agent, which extends gnupg to play nicely with Windows sockets. 
Wed, Nov 10
I compiled the Appimage with the scripts in Gpg4win and it runs Kleopatra and works :-)
Nov 2 2021
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.
Oct 31 2021
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.
Oct 19 2021
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
Oct 11 2021
Fix for this issue landed RNP master, and will be included to the RNP v0.16.0 release.
- 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
Oct 10 2021
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
Oct 8 2021
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.
Sep 29 2021
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).
Sep 28 2021
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.
Sep 27 2021
Sep 23 2021
Sep 21 2021
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.
Sep 20 2021
- >>gpg2 --version
gpg (GnuPG) 2.0.30 (Gpg4win 2.3.3)
@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:
During further work on this got another issue:
Sep 17 2021
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.
Sep 16 2021
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. :)