Re: Certbot, Ring in Debian Stretch
On 22/11/16 02:40, Peter Eckersley wrote:
> 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.
>
Thanks for raising this Peter
This is not just an issue for certbot, it is also an issue for any
package that supports an evolving networked service. It is a particular
challenge for software in the real-time communications space (e.g. SIP,
XMPP, WebRTC). The exciting new peer-to-peer Ring[1] client is also
evolving quite rapidly like certbot and stale versions will impact the
success of that initiative.
The approach we take with the freeze is good for certain types of things
(e.g. compilers and scripting languages) and backports has helped
mitigate this as you already observe.
> 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:
I'd like to suggest an additional point relevant to all of the options:
how well does the certbot client react when it is no longer usable?
Does the protocol include a mechanism to check the version? Does the
client give an explicit error telling the user to update the client and
can it be tweaked so that Debian users are shown a message about getting
the latest package from stable-backports? Or will the user see some
random error that doesn't mention the client version at all?
>
> 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.
>
>From my experience as an upstream developer, trying to do this type of
thing for multiple distributions becomes time consuming and tedious and
it takes time away from the upstream work. If your primary focus is
upstream development and standards work it can be difficult to also be
fluent in the rules of every distribution, it becomes quite tedious.
This workflow tends to work better where other volunteers within the
distribution are willing to prepare the uploads to stable-updates and
equivalents.
> 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.
>
>
1. https://packages.qa.debian.org/r/ring.html
Reply to: