Non-interactive PIN not accepted, gpg hangs

[Laurent Blume]

Le 2015/09/30 13:19 +0200, Peter Lebbing a écrit:
> On 30/09/15 11:20, Laurent Blume wrote:
>> I really, really need it to be non-interactive.
> 
> You can't unlock the card when the server is booted and then leave it
> unlocked for the whole time the server is up? You could do it in an SSH
> session, when correctly set up.

There are human resource issues there, but let's focus on the technical
side.

I've thought about it, but it's not that obvious to set up. It depends
on scdaemon, which is started by gpg-agent.
It means I would need to create a gpg-agent service, which would run
scdaemon reliably. What would happen if any of them dies for $REASON?
Unexpected breakage that would make a lot of people very unhappy.

However, I think I will do that using a custom pinentry that feeds the
PIN to the card automatically. I can already foresee annoying side
effects. Like having to stop the service before doing any key management
operation, so I can start a «normal» gpg-agent, then not forgetting to
restart it. It means anything using it will need a layer of checks to be
sure it's available.

> The OpenPGP Card does not permit operation without a PIN.

Sure, but I don't see why the entry of a PIN was artificially forced to
be interactive. Even if I get it to work, I'll be worried it's a brittle
solution.

> There's a new feature in 2.1, loopback pinentry. Perhaps that allows you
> to provide the PIN non-interactively on booting up the server? I haven't
> tried the feature, though. Loopback pinentry is the replacement for
> --passphrase-fd, AIUI.

I've heard of it. At this point, 2.1 can't be an option, because there's
no official support, no even RPM for it.

Laurent