Hi Harlan, On Wed, 15 Jun 2016 at 22:30:18 -0400, Harlan Lieberman-Berg wrote: > I'm curious about how you would differentiate a package like this from > the other ACME clients out there -- I know specifically letskencrypt > seems to fall in the same kind of category (highly isolated > components; it uses pledge(2) and chroot(2) as well).
I was not aware of Letskencrypt :-P. lacme development started in early December 2015 because at the time I was not happy with the ACME clients offer out there. It has expanded quite a bit since [0], and I'd some time to checkout all the clients. I'm glad to learn I wasn't the only one raising concern with the monolithic approach of the official client, though. But as far as I can tell, lacme's account key management is unique in that it enables storing the account key on a different host (using the UNIX-domain socket forwarding facility of OpenSSH 6.7), optionally PGP-encrypted. IMHO this is a desirable property as I'm not satisfied with the current compromise that having early expiration dates forces site operators to use (and therefore expose) account keys more often. (On a side note I'm looking forward to GET renewal being implemented in boulder [1].) An alternative solution would be to store the account key on a smartcard; adding smartcard support would be trivial to implement in lacme, but I don't own one to test it out :-P. Another feature of lacme is that it is not limited to webservers: for instance one can automatically issue a certificate for a MTA even when there is no webserver running on the host. iptables(8) rules are then added on the fly (and removed afterwards), and a tiny webserver is spawned to handle the "http-01" challenges. However, while lacme can execute an arbitrary command to restart or reload a given service, it will not automatically modify server configurations. (This is a deliberate choice.) > I also want to make you aware of the Let's Encrypt Debain Packaging > Team, in case you were interested in having the package be co-maintained > with us (with the team in Uploaders), or maintained under that heading > entirely (with the team in Maintainer). Thanks for coming forward! I was aware of the team, but didn't dare to drop you a line :-/ I would be happy with co-maintenance (with the team in Uploaders). Cheers, -- Guilhem. [0] https://github.com/certbot/certbot/wiki/Links [1] https://tools.ietf.org/html/draft-ietf-acme-acme-02#section-6.5
signature.asc
Description: PGP signature
