Non-interactive PIN not accepted, gpg hangs

[Peter Lebbing]

On 30/09/15 14:04, Laurent Blume wrote:
> There are human resource issues there, but let's focus on the technical
> side.

Yes, I realise that.

> 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.

Processes dying tend to cause breakages in general. The issue here,
though, is indeed that simply restarting the process isn't enough.
That's where a custom pinentry could help.

In principle, it's not difficult to set up. If you want to account for
processes randomly dying, then yes, it gets difficult, I agree. But a
custom pinentry could save the day.

> 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.

I think it's not that bad, actually. I think in the general case your
gpg-agent/scdaemon with loopback pinentry would be restarted
automatically if it wasn't available. So you'd "just" have to switch to
a normal pinentry when you need to do something requiring the Admin PIN.
Is this really something you foresee happening though? I think switching
keys on the card is going to be a downtime-incurring operation anyway,
since it's not atomic. On-disk keys are much more flexible in that respect.

IMHO, you're using a device meant for personal usage as an HSM. It's
possible, but your use case is a relatively unusual one, and might
require some tweaking indeed.

> 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.

I take it you mean /downstream/ official support, then. Upstream support
is fine :). Anyway, a custom pinentry it is, then :). With 2.0. I
wouldn't recommend 1.4 with agent, since it is less seamless, and you're
gunning for seamless. When people recommend 1.4 for headless servers, I
don't think they mean using a gpg-agent with scdaemon.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>