[Letsencrypt-devel] Bug#827425: RFS: lacme/0.1-1 [ITP] -- ACME client written with process isolation and minimal privileges in mind

Guilhem Moulin guilhem at guilhem.org
Thu Jun 16 10:03:02 UTC 2016


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/letsencrypt-devel/attachments/20160616/28b6959e/attachment-0001.sig>


More information about the Letsencrypt-devel mailing list