I try experiment using Python PKCS#11 (https://python-pkcs11.readthedocs.io/en/latest/index.html)

• with SoftHSM https://github.com/opendnssec/SoftHSMv2
• with Scute

I concluded that (at first, for the initial try) it's not good to start this under scdaemon, because of two different abstractions for accessing the device (the way of scdaemon and the way of PKCS#11).
It's good to start with something like tpm2d. The goal would be integration into scdaemon or tpm2d.

Sorry, I mistakenly closed this task. I reopen it.

Could it be the case that your implementation actually used those bits to calculate a public key?

For a device which only provides PKCS#11 driver, I decide to test with SoftHSM.

Current status:

• Gnuk Token, Yubikey, OpenPGPcard with some card readers (only w/ specific reliable card readers)
• some cards some card readers (many are not supported well)
• TPM

@MathiasMagnus This change is to support Win32-OpenSSH by gpg-agent emulation of ssh-agent; You can use gpg-agent emulation of ssh-agent when you use Win32-OpenSSH. That is, you can use GPG auth subkey for Win32-OpenSSH.

The interaction goes back to "Your decision?" after you didn't answer "y/N" to the question of "Do you really...?".
What you are asked is: 1, 2, 3, 4, 5 or m.

Some technical points:

Thank you for the patch.

Thanks a lot.

Not yet fully finished, but it's better for me to put it now:

I leave this open as ticket for the rest ?

Here is my fix:

Here is my change for libkleo Japanese Translation:

My understanding is that: selftest in Kleo does call assuan_socket_connect (possibly in kleopatra/src/libkleopatraclient/core/command.cpp), and it didn't send nonce correctly.

I found an issue in the assuan code of client side. This might be the cause of the server failure for nonce.

Well, not our bug... it's a kind of support question and answer:
This might help: https://stackoverflow.com/questions/3844393/what-to-do-about-pty-allocation-request-failed-on-channel-0

Pushed the change.

Ah, I had not done git pull for a week, and I didn't realize your patch.

Something like this should fix the behavior:

diff --git a/src/argparse.c b/src/argparse.c
index ef0c161..403c4a7 100644
--- a/src/argparse.c
+++ b/src/argparse.c
@@ -3000,7 +3000,13 @@ show_help (opttable_t *opts, unsigned int nopts, unsigned int flags)
         writestrings (0, "Options:", "\n", NULL);
       for (i=0; i < nopts; i++ )
         {
-          s = map_fixed_string (_( opts[ordtbl[i]].description ));
+          if ((opts[ordtbl[i]].flags & ARGPARSE_OPT_HEADER)
+              && opts[ordtbl[i]].description
+              && !*opts[ordtbl[i]].description)
+            /* It's empty header.  */
+            s = opts[ordtbl[i]].description;
+          else
+            s = map_fixed_string (_( opts[ordtbl[i]].description ));
           if ( s && *s== '@' && !s[1] ) /* Hide this line.  */
             continue;
           if ( s && (opts[ordtbl[i]].flags & ARGPARSE_OPT_HEADER))

I will push this change:

commit e89d57a2cb10bd04d266165015f159be2ab48984
Author: NIIBE Yutaka <gniibe@fsij.org>
Date:   Wed Dec 21 10:52:24 2022 +0900

I figured out the situation.

Ah, I found that we have very bad example use case in tests/t-mpi-point.c. This should be fixed at first.

Thank you for your report. IIUC, it is called unexpected way, like invalid/wrong KEYPARMS. Possibly, KEYPARMS == NULL, or something like that.

Here is my try of next, after 0001.

Here is my try:

AFAIU, gpgrt-config works well now for the multilib MinGW target.

Thank you for your report.
Please look T6204.
Closed as duplicate.

Fixed in rG8e8971403f75: w32: Fix gnupg_unsetenv..

Pushed the change.

Now, the use of AM_PATH_GPGME_PTHREAD shows warning. Also I update the documentation.

Modern way for license notice seems use of URL: https://www.gnu.org/prep/maintain/maintain.html#License-Notices-for-Code
https://www.gnu.org/licenses/gpl-howto.html

@ametzler1 Thanks a lot for your help.

Sorry, it looks like no problem.

Implications are... you won't be possible to use new protocols introduced by newer OpenSSH: