[Letsencrypt-devel] Certbot in Debian Stretch

Peter Eckersley pde at eff.org
Tue Nov 22 01:40:22 UTC 2016


Hi!

I'm an upstream developer for Certbot, previously known as the Let's Encrypt
client (https://certbot.eff.org). Certbot is a flexible and very popular way
to get certificates from Let's Encrypt; it's issued about 300,000 currently
active TLS certs to Debian servers (and a lot more to Ubuntu servers). We hope
that over time, a lot of server software can be well-integrated with Certbot
in order to use authenticated TLS connections by default (see
https://certbot.eff.org/docs/using.html#plugins for some of the integration
efforts to date).

We're writing to figure out a plan for Certbot versioning and updates for
Stretch's stable lifetime. Certbot is still a fairly rapidly-improving,
not-quite-1.0 piece of software. The ACME protocol that it uses to talk to Let's
Encrypt is also rapidly evolving through an IETF working group
(https://datatracker.ietf.org/wg/acme/charter/), and the Let's Encrypt
server-side codebase (https://github.com/letsencrypt/boulder) is 
currently working with an ACME backwards compatibilty window of 6-12 months,
but probably not longer than that.

In order to both ensure that Certbot remains compatible with the deployed
Let's Encrypt service, and to ensure that users have as good an experience as
possible when they use Certbot, we do not think it would be wise to support a
specific version of Certbot from the Stretch freeze early next year through to
the EOL of that release.

There seem to be a few options available:

1. Leave Certbot out of the Debian Stretch release, and rely on
backports as the recommended way to run Certbot on Debian. That's what we
currently do with Jessie:

https://certbot.eff.org/#debianjessie-apache

2. Periodically declare a released version of Certbot to be well-tested,
stable, and free of detectable regressions or breakage of existing workflows,
and include it in Stretch's stable-updates repo.  We're currently trying the
Ubuntu equivalent of this process out with a proposed xenial SRU from
letsencrypt 0.4.1 to Certbot 0.9.3:

https://bugs.launchpad.net/ubuntu/+source/python-letsencrypt/+bug/1640978

We expect that such updates would occur every ~3-6 months. If the Debian
development community agreed to such a plan, we'd feel comfortable working
with it.

3. Someone could maintain a fork of a near-future Certbot release for the ~5
year lifecycle of the Stretch Debian release. The upstream team definitely
doesn't think this is a good idea, and we don't have the resources to support
such an effort.

Looking at the three options above, I think we'd default to doing 1, but we
would be open to pursuing option 2 if the Debian developer community supports
it, and think there could be advantages in terms of allowing other packages to
assume that Certbot is installable, or even Depend: on it, for enabling TLS.


-- 
Peter Eckersley                            pde at eff.org
Chief Computer Scientist          Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993



More information about the Letsencrypt-devel mailing list