OpenSSL is considering a more aggressive EOL policy | Hacker News Reader

OpenSSL is considering a more aggressive EOL policy

lists.freebsd.org

36 pointscnst26 comments

A couple of replies in, they say "In other words, the idea that you can pre-declare a lifetime is fantasy." The thing is, it's really not. You say "we'll support version <foo>", and that means that you release security fixes for <foo> that don't change anything else. It's then easy for maintainers to decide whether the need for the security fix affects them or not.

The alternative is discrete versions where any number of things can change between versions, but you have to accept everything in order to receive security fixes. In some instances, those are inevitably going to break backwards-compatibility for at least someone despite all best efforts, and this may even kick off regulatory compliance procedures.

Either way, distros are going to continue to do the "we'll support version <foo>" thing, so this is basically offloading the need to carve out security patches to them. In some cases, they might even have to write the security patches themselves. And this is supposed to make our systems more secure?

I can't wait for LibreSSL to be usable, if this is how the OpenSSL developers think.

Yep. OpenSSL is too important and widely used software to not have security-fix-only patches for at least several years (if not more) of releases.

If the only way to get security fixes is to update to a new version that has other changes that may accidentally break things -- this is really bad for such a key piece of (security!) infrastructure.

I'm not really sure how long you consider "at least several years"* to be but the version they're talking of EOLing is nearly a decade old and v1.0.0 is already 4 years old and not looking to be EOL'ed any time soon (even if their 2 stable branch strategy comes into play).

I'd say that's more than enough time for maintainers downstream to upgrade (and it's already longer than most software stays supported for - so if maintainers aren't pushing updates then there's going to be other layers of the stack that's unpatched and thus vulnerable).

That does seem potentially reasonable, you're right. I think the longer the better with this sort of thing, but it has to be balanced with available resources.

10 years would seem to me to be above the minimum required though, you're right. I'm not sure how far under 10 years I'd be willing to say that for.

And no matter what is reasonable -- there WILL be software still running that's even older than 10 years, for which there's no longer any developers confident they can update to a new version of OpenSSL with potentially backwards-breaking changes. Reasonable or not.

I'll point out that RHEL releases are supported for 13 years, CentOS seems to be 10, so supporting a critical piece of infrastructure for 10 years does not seem out of place.

An observation: you all are quick to demand other folks do work for you.

There is a choice of whether to use free software or not. The choice is made, in part, on perceived quality including robustness of the maintenance and release process.

And people make these evaluations by talking about them on the internet. That's how it works, that's what we're doing.

There are other considerations, like cost-of-switch and availability of suitable alternatives, sure.

But we talk about this all on the internet. Same as 'demanding' that someone fix heartbleed or other bugs in OpenSSL for us. Nobody has to do anything, but there is a point at which people will start looking for alternatives if things aren't done. And people talk about what that point is on the internet.

The pre-declared lifetime worry seems unsubstantiated in my opinion. There's no reason why OpenSSL can't have an expected life cycle based around the expected release of the next new version number. eg 1.0.2 might have an ETA of Jan 2015 and 1.0.3 of Jul 2016; so then you know that 1.0.0 will EOL at Jan 2015 and 1.0.1 18 months later.

I do agree that there needs to be some predictability but I also think managing 4 (including betas) code bases add a lot of unnecessary maintenance. If they can remove one branch, enabling them to better focus their time, then I can't see that as a bad thing nor mutually exclusive from having pre-defined EOL dates.

FreeBSD has four releases of their entire operating system in support right now, across three major versions, supported almost entirely by volunteer work. If OpenSSL can't support four minor versions of their security-critical codebase, I don't think it's possible to trust them.

Yeah true, however I don't think that's a fair comparison. Maintaining older FreeBSD repos wouldn't require large amounts of original code in the same way as maintaining multiple branches of OpenSSL.

Plus the "security-critical" part of your post needs to be emphasised.

> Maintaining older FreeBSD repos wouldn't require large amounts of original code in the same way as maintaining multiple branches of OpenSSL.

Really? FreeBSD repos contain large amounts of both original and external (sometimes modified) code. If there's a security issue, it's entirely possible that all of them need patches.

/positive

Please consider donating to LibreSSL, again if you can. It would take less time than grammar-checking your comment :)

As a lay developer I can only hope that the people in linux, *bsd lands are working on the problem diligently.

Surprisingly Microsoft has its own SSL stack. Any thoughts of opensourcing from their end would be interesting, especially if they have nice test suites.

Just a note: you can't really donate specifically to LibreSSL. LibreSSL is part of the OpenBSD source tree (libssl), so you donate to the OpenBSD Foundation as a whole. You can specify that you'd like the money to go to X project, but it's ultimately their choice to respect that or not.

> "We (the OpenSSL team) are considering a more aggressive EOL strategy.
> In particular, we may EOL 0.9.8 right now, and 1.0.0 when 1.0.2 comes out (currently in beta).
> Going forward we would only maintain two versions, so when 1.0.3 comes out, 1.0.1 would be EOL.

> What do people think about this?"

Makes a lot of sense in my opinion

The headline, while matching the article, is misleading. This is about OpenSSL's EOL policy, not an EOL for OpenSSL itself.

We changed "strategy" to "policy" in the title in an attempt to address this. Happy to change it again if anyone suggests a more accurate one.

Is there a changelog of headline changes?

My original headline didn't have the word "strategy" in it, so, someone must have changed it prior to your change, too!

Oops; I think another moderator and I changed it at approximately the same time. The submitted title was "Ben Laurie (OpenSSL core team): OpenSSL end of life".

I dare say most people who read the headline knew OpenSSL wasn't planning on killing itself after getting a few million dollars in funding.

Doing X number of release back doesn't seem work to me, at least for something like OpenSSL that's often embedded in devices and other software. That is unless the release is on a fixed schedule like Ubuntu or OpenBSD.

Maybe do like Ubuntu. You can have a long term support version, or you can use the latest and greatest, but it will be supported for a much shorter period of time.

In any case I think they should focus on predictability, that is do a major release at fixed times. If something isn't ready at that point: Tough, it has to wait until the next release. OpenSSL isn't a company of cause, so they don't need to please their user, but it would be an easier sell if I knew the the time frame in which I can expect support and updates for a given version.

I wonder how this is going to impact those distributions that do long term support releases like Ubuntu/Debian.

Given that so many have not wanted to look into the OpenSSL source code, that could actually get really ugly. Some operating systems and distributions would need to back-port bug fixes. That would be a rather large undertaking given the quality of much of the OpenSSL code.

In case anyone else was confused as I was, it looks like OpenSSL uses letters at the end of the full version number to indicate the release. So, '0.9.8' actually has multiple releases, it's currently on '0.9.8za'.

The version numbers are different code bases and the letters are different patch versions.

Not really sure why they didn't go for the major.minor.patch convention like a lot of other software does, but it's all just arbitrary at the end of the day.

Reading their lists and applying patches would be more "aggressive".

Even the ability to write proper code would be a more aggressive policy.

they would do better to start asking who uses what feature, and removing unused ones.

Reply on news.ycombinator.com