command 'LEARN' failed: No inquire callback in IPC

[NIIBE Yutaka]

Dustin Rogers <dustincr at hotmail.com> wrote:
> In fact the native support for smart cards does not seem to support
> network attached HSM "virtual tokens" devices at all. It could be
> possible that I need to specify the local port the installed HSM agent
> is running on, but I dont think I will be that lucky.

No, scdaemon doesn't support it.

> I have this  other scdaemon (gnupg-pkcs11-scd) working fine with gnupg 2.0,

Well, I think that gnupg-pkcs11-scd is not supported by GnuPG, 2.0 or
2.1.  It is a kind of... independently developed program, unfortunately.
It was just coincidence (from my view point) it worked with GnuPG 2.0.

It would be good if someone around gnupg-pkcs11-scd shares developement
information with GnuPG.

> but with manual pinentry for each operation. I cant get it working
> with gnupg 2.1. (again, I am looking for the unattended pinentry
> support the later version seems to have) Thus, I really dont think
> this is an issue with the scdaemon I am using. Moreover, I can see the
> INQUIRE PIN callback is there, the pinentry is just not
> appearing. Really I would like to understand why the gpg-connect-agent
> is allowing the pin call back through, and the gpg-agent itself is
> not?

Well, it's the detail of protocol between gpg-agent and scdaemon.
INQUIRE NEEDPIN from scdaemon is not expected by gpg-agent when LEARN
--force is issued.  This situation is same in GnuPG 2.0.

We don't know how gnupg-pkcs11-scd works, according to your log, it
breaks the protocol for LEARN.

gpg-agent only delegates back the INQUIRE NEEDPIN request to gpg when it
is prepared: PKSIGN, PKDECRYPT, WRITEKEY, and generic SCD.

For gpg-connect-agent with SCD command, it is prepared, thus it works.

I think that it would be good to check why gnupg-pkcs11-scd called back
with INQUIRE NEEDPIN for LEARN command.
--