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 p...@eff.org Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993
