Live data from Hacker News

OpenSSL is considering a more aggressive EOL policy

lists.freebsd.org

11–20 of 28 posts

Re: OpenSSL is considering a more aggressive EOL policy

#11
post #9

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 ", and that means that you release security fixes for 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…

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 (…

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.

Re: OpenSSL is considering a more aggressive EOL policy

#12

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 ", and that means that you release security fixes for 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…

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).

Re: OpenSSL is considering a more aggressive EOL policy

#13

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 ", and that means that you release security fixes for 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…

/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.

Re: OpenSSL is considering a more aggressive EOL policy

#15
post #9

Earlier quoted context omitted.

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 (…

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.

Re: OpenSSL is considering a more aggressive EOL policy

#16
post #8

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!

Re: OpenSSL is considering a more aggressive EOL policy

#17
post #16
post #8

Earlier quoted context omitted.

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".

Re: OpenSSL is considering a more aggressive EOL policy

#18
post #13

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 ", and that means that you release security fixes for 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…

/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.

Re: OpenSSL is considering a more aggressive EOL policy

#19
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.

Re: OpenSSL is considering a more aggressive EOL policy

#20

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.
Post reply on HN