The OID is used for fingerprint computation, which complicates things.

Using the shorter OID for v5 is on purpose; thus we need to fix the export.

I don't think it makes sense to add such a feature/bug fix to the old versions.

Please go ahead and apply to master. I'll take then care of backporting.

Done in GnuPG 2.5.0.

This fix has the problem that for a signed message where the signing key is not available gpg emits the decryption_failed status line and prints "WARNING: encrypted message has been manipulated". This is because we use log_error to show that the signature could not be verified due to a missing key. The extra check we introduced with rG50e81ad38d2b lloked at the error counter and thus triggered the decryptio failed.

See new subtask T7290 for smartcards and the link entries mentioned above.

So we need a way to launch scdaemon via userv and make sure that the scdaemon user gives proper permissions to its socket file. gpg-agent also nees to check for a proper version of scdaemon and gpgme needs to be aware of this as well (if it want to directly connect to scdaemon).

Testing dirmngr by /home/gniibe/build/mingw-i686/gnupg/bin/gpg-connect-agent.exe --dirmngr 'loadswdb --force' /bye (configured distsigkey.gpg beforehand), I confirmed it works well now.

Fixed in: rG862448216035: common:w32: Fix INEXTRA handling.

This is related to T6818

Yes, I think we should support this. Also X448. Thanks for the report and the samples.

Note that this has also been ported to 2.4 and 2.2 and tested by looking at the status lines.

Thanks for reporting this. Returning error codes to upper layers is not always easy because the original logic is that we have a global error counter to decide whether an operation succeeded. My fix to check the error code before emitting the DECRYPTION_OKAY status,

It's true that for KEYTOCARD command, there is optional argument for ECDH.
My point is that for PKDECRYPT command, it will be needed to add mechanism for getting such a parameter (when we use KEM API in gpg-agent).

We already have the ECDH parameters for OpenPGP in the gpg-agent API. The question is how large the data for PQC will be - likely we need to use an inquire already for this reason.

Considering the design of gpg-agent which focuses on private key operations and data, it would be better to enhance the gpg-agent protocol to inquire public key data of any format defined by the client (including ECDH KDF parameters of OpenPGP). I mean, instead of storing data in the key file (originally designed for private key + some additional data), we will enhance the protocol.

Please excuse my question but this issue has been WIP for 8 months. I think it was forgotten a bit. Especially since we are not shipping Okular for general signing of PDF documents this issue might help as a stopgap for Smartcards which we do not yet support natively and reduce the pressure a bit to add more PKCS#15 smartcards which can currently be used with Adobe and Mozilla NSS through their proprietary PKCS#11 modules. So I would like to raise the priority for this a bit. But I don't think high is appropriate. That would be for werner to decide.

Sorry, I only now noticed that you used the --export-secret-ssh-key. Unfortunately commit
rGafe5fcda52e88438c7a7278117b2e03f510a9c1c states in the comment:
"Due to time constraints the code is not yet ready." Let's turn this into a feature request.

assuan_sock_accept approach is taken in gnupg master.

gniibe/t6606 patches are all pushed into master.

Applied: rGb8c5d99406c9: gpg,agent,kbx,sm,scd,tpm2d,g13: Use assuan_control.

In T6606#173044, @gniibe wrote:

More care is needed to be perfect; There are places in GnuPG where assuan_sock_connect may be used before syscall clamp set up (after the first assuan_sock_bind failure).

Applied to master.

Applied the changes for libassuan T6487 into gniibe/t6606.

Pushed the change in gniibe/t6606 branch.

Another approach would be:

• Use assuan_sock_accept which has consistent API with gnupg_fd_t