[Letsencrypt-devel] Certbot in Debian Stretch

[Peter Eckersley]

On Wed, Nov 23, 2016 at 09:57:19AM +0100, Thijs Kinkhorst wrote:
 
> I'm a bit surprised by this policy. To my knowledge, concepts like automation
> and "hassle-free" are central to the Let's Encrypt concept. Obviously are
> online for more than a year, so installing Let's Encrypt certificates on them
> is not quite automated or hassle-free if you need to upgrade certbot several
> times during the projected lifetime of the server.
> 
> Is it really necessary to have such, in my opinion, really short API
> lifetimes?
> Surely you want to extend and develop it, but this can be done while keeping
> compatibility with existing clients in the field.

I think this is a pretty profound strategic and philosophical question :)

What I hear from the boulder development team is that supporting old versions
of the protocol on the server side will greatly complicate their work: they'll
either have to maintain many more code paths within a given application (to
support different call semantics in different versions of the protocol) or
support multiple instances of the CA application talking to the same back-end
databases. In one case they'd have to stick with an old version of the Go
language, because Go 1.7's standard library implemented better CSR checking,
which exposed a Certbot CSR formatting bug.

The boulder team's philosophy is to deal with these engineering difficulties
by being fairly agressive in pushing clients to take regular updates. They're
willing to maintain support for prior protocol versions, but only for a
limited amount of time. I think that "get everyone to run the latest and
most-correct code" approach is a fairly common attitude especially amongst
security-focussed projects.

But there are of course drawbacks: it makes life harder for projects that (in
relative terms) place a higher priority on stability vs security. And that's a
legitimate choice for many purposes.

So Let's Encrypt definitely wants to get to a place where we have some very
stable APIs for other people to code against. We're trying to do that with the
Certbot command line itself, working hard to ensure that if people upgrade, it
doesn't break scripts they might have written around the client. And in the
long run, I suspect ACME will mature and stabilise too.  But it's especially
tricky to expect long-run-future-compatibility from a service that's only been
online for a year.

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