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

While data template preparation for RSA-PSS is a bit tricky, it's simple with ECDSA.

Having hash-algo in the s-exp is useful because a hash handle may carry several hashes. This is sometimes useful if you do not know the hash algorithm in advance and you need to make a guess (various PGP compatibility things in gpg). But of course we can simplify this and use the default algo from the hash handle if hash-algo is missing.

Thanks for your comment.

Thank you. On the first sight, it looks reasonable, but I would like to experiment with it a bit to see all use cases are covered.

Some quick ideas: On Windows we have envvars (and APIs) to determine certain locations. There is also the registry. We use of all them. IT would be best to do this simalar on Unix. We also have a control file on Windows which switches to that portable mode; maybe it is best to do this also on Unix - A text file installed alongside gpg which gpg (common/homedir.c) uses to enable the use of certain envvars to locate the root etc..

Pushed my initial implementation: rC117f5c3f8028: experiment-pk_hash_sign/verify: Implement pk_hash_sign/verify.

I am doing an experiment to implement gcry_pk_hash_sign.

One challenge of the AppImage is how to make gpg and its helpers use the helpers baked into the AppImage. Currently, everything is built with prefix /build/AppDir/usr. This causes

gpg: failed to start agent '/build/AppDir/usr/bin/gpg-agent': No such file or directory

unless gpg finds an already running agent.

Won't be implemented as a new option because --check-sym-passphrase-pattern and --check-passphrase-pattern (since 2.2.30) can be used to implement the same in a more flexible way.

My suggestion for a combined function is a simple:

2021-09-13 Update:

• Signature operation tested: RSA-PSS, RSA-PKCS#1-v1.5, RSA-X9.31, ECDSA by NIST Curves, DSA (against CAVS test vectors in FIPS 186-4)

In T1621#149541, @werner wrote:

GnuPG stable (i.e. 2.3.2) has full support for several readers and tokens. This won't be backported to the LTS versions (2.2), though. Better switch.

GnuPG stable (i.e. 2.3.2) has full support for several readers and tokens. This won't be backported to the LTS versions (2.2), though. Better switch.

I've recently acquired two Yubikeys: one Yubikey 5 NFC from my workplace, and shortly after, I bought a Yubikey 5C for my own personal keys… both security tokens have _different_ keys on them. (There are some questions being asked regarding the use of the same GnuPG key duplicated on separate smartcards; this is a different case).

Interesting idea.

How difficult would it be to teach gpg-agent to fall back to another SSH agent if given an unsupported key?

Which product do you refer to? Kleopatra? gpg4win? Something else?
Which operating system are you using? Windows? Linux? Something else?

I see.

BTW, the reason of the name "pkey" is that because gcry_pk_ctl is already occupied.
It will be changed, if needed.

Today, I pushed an example for RSA-PSS.

I added couple of minor comments. I hope they went into somewhere.

I created an experimental branch:
https://dev.gnupg.org/source/libgcrypt/history/gniibe%252Fnew-pk-api/

Thanks for helping out @werner.

You can write your own pinentry script instead of the loopback thing. The use the envvar PINENTRY-USER_DATA to communicate with the pinentry.

by the way when the applet is selected, I return
D2760001240103045343000000010000
this can be used to detect the manufacturer number

Card ATR at the cool reset
Card ATR is : 3B 9C 95 81 01 50 53 43 50 2D 53 43 53 56 31 2E 30 8E
Historical Byte is 53435356312E30
CARD ATS-to-ATR is : 3B 8C 80 01 50 53 43 50 2D 53 43 53 56 31 2E 30 0A
CARD ATS is : 11 78 80 B8 02 50 53 43 50 2D 53 43 53 56 31 2E 30
Historical Byte is 53435356312E30
This can by detected for the card type.

Is there another way to to detect your card (I assume a Javacard) without relying on the openpgp card application vendor-id like we do it with the Yubikey? I want to avoid a possible early but expensive AID selection just to get the vendor-id.

Actually, I think there's a way to make gpg_strerror_r more usable on its own. I previously said

I find it quite difficult to use strerror_r and gpg_strerror_r. With having to guess and retry to get an appropriate buffer length, a wrapper which dynamically allocates the string seems to be needed.

At first I've had simply tried to give multiple --symmetric options (which of course didn't work).

I have no clear idea on how to style the UI for this feature. Technically it is simple but we need top query several passphrases. loopback mode with a list of passphrases might be easiest way to do that.