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> _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
