No, our admin left us and took all scripts and docs with him. We need to set it up again. You better use this system anyway, patches etc on GitHib are not used.

GnuPG requires a Unix system to build. We do not support building natively on Windows. Sorry.

Okay, I revisited the code:

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.

The internal hashing of ed25519 is not used by OpenPGP but instead we pass the hash of the message to the ed25519 function and thus to the card. Pushing a message through a card is a no-go - way too slow for any normal sized message.

That does not seem to be right. You don't need 255 bytes for an ECC key. It would be best to get scdaemon logs simialr to the gpg-agent logs. Set "debug ipc,cardio" into scdaemon.conf.

What is the rational for this change?

Yes, keep the internal SHA-3.

Blowfish is not part of OpenPGP and according to its creator not the best cipher. Sorry to say no. You may nevertheless be interested in the recent discussion threads on PQC on the cryptography ML.

Closing. In case the audit will request more, we can re-open this task.

I think we can close this. In January we will have an external audit (BITV) which hopefully will confirm our tests. They auditor will also provide a list of things to improve (if any).

Please no new levels. And also consider the problems with global config files, conditionals and values taking from the registry. We can't simply do everything in the GUI - it would get too complex and we end up supporting the supportive config dialogs. Maybe a syntax checking editor would eventually be better.

OpenPGP folks now the algo number by heart ;-)

Fixed and tested on Linux. Thanks.

Sorry, I obviously forgot to add this vendor.

Having it invisible is okay for me. But we should not support the keyserver option in gpg.conf via Kleopatra anymore. This option needs to be faded out. Actually there are more problems in 2.2 here: In particular the global options are not manageable by a gpgconf. Thus there is no guarantee that the keyserver option actually shows the correct value if global options are used.

FWIW, GPA has a setting where you can select at which level options are shown (but not invisible). IIRC we had the same in Kleopatra but it has been removed.

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.

Actually we do not really support the systemd thing and it is likeley that the support in GnuPG will eventually be removed again. You may want to contact the Debian maintainer, who took responsibility for all systemd things.

Does the key have a passsphrase or somehow the empty string as passphrase?
If you don't use lookback mode: does the pinentry pop up?

(I edited the report to make it readable, but did not yet looked at it in detail)
I wonder why you are using a decent libgcrypt but a 3 years old GnuPG version?

Sure there are logs, see the options log-file and debug in the man pages.
To sign using specific subkey or the main key, use the fingerprint of the key and append an exclamation mark.
For example

I think we can close this bug. The warning will now only be printed as part of the the regression test and after all it is just a warning.

Will go into 2.3.4 which will also silence the noise of not being able to read it. The major reason for this code is to allow building an AppImage.

Thanks for the patch. That is sufficent. I added you to the Contributor group, though.

The thing is that any n.m.k-something version should behave versionwise the same as n.m.k. That is okay, because beta versions etc are not considered to be released. This is required to allow testing beta version _before_ doing the release.