Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The problem is that Letsencrypt is, while useful and important (and free, let's not forget that!), one of those "if it works perfectly, you won't notice anything at all" things. Users don't need to interact actively or regularly with it at all, that's one of its main value proposition.

So how exactly are they supposed to handle a breaking change? Just never have any breaking changes, ever? What if a breaking change is necessary for security reasons, with security being, after all, the primary reason for the project to exist at all?



> Just never have any breaking changes, ever?

Absolutely, that is the correct answer.

If a breaking change is absolutely needed that implies a new major release number, but never, ever, break compatibility in the current major release family.


Absolutely not, that is the wrong answer.

If a security-critical issue cannot be fixed without a breaking change, you make that breaking change. Anything else is irresponsible, as is the desire of users to keep running insecure systems to avoid the effort of updating them.


> and free, let's not forget that!

If they can't run a reliable professional service doing it for free - stop lying about that and claiming you're a valid alternative to buying certs once a year from incumbent vendors.


This has nothing whatsoever to do with realiability or professionalism, much less is it related to funding, and it very much is a valid alternative.

A very expensive paid service might be able to offer direct support that walks you through the upgrade procedure in common setups, that's about it.


The _worst_ of the shitty alternatives, let’s say GoDaddy, have this approach where the mechanism by which I update the ssl certs they provide has remained the same since, honestly? Probably the Mid/late 90’s which was the first time I added an ssl cert to an Apache config. GoDaddy have made exactly zero breaking changes in those intervening 20-25 year.

If this had been due to an actual critical security breach in ACMEv1, then maybe doing it would have been excusable - but even then, doing it without proactively contacting every user of their certs to let then know would have been inexcusable.

So far as I can tell though, the ACME 1->2 “upgrade” was closer to”Oh, we didn’t like the old guy’s code, so we rewrote it. It’s almost the same, but better! It passes almost 70% of the tests, so we decided versioning things so we could maintain backwards compatibility was too hard, so it sucks to be running a stone ages website that’s over 180 days old - who even are those losers? YOLO!”


They could simply decide not to break it.


Which would be the wrong decision if there is a security-critical issue that cannot be fixed in any other way.


Was there though in this case? I don’t think there was.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: