command 'LEARN' failed: No inquire callback in IPC
gniibe at fsij.org
Wed May 17 08:31:44 CEST 2017
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
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.
More information about the Gnupg-users