OpenSSL is considering a more aggressive EOL policy
lists.freebsd.org
OpenSSL is considering a more aggressive EOL policy
1–10 of 28 posts
Re: OpenSSL is considering a more aggressive EOL policy
#2The headline, while matching the article, is misleading. This is about OpenSSL's EOL policy, not an EOL for OpenSSL itself.
Re: OpenSSL is considering a more aggressive EOL policy
#3> "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
Re: OpenSSL is considering a more aggressive EOL policy
#4In 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'.
Re: OpenSSL is considering a more aggressive EOL policy
#5A 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 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 " 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.
Re: OpenSSL is considering a more aggressive EOL policy
#6In 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.
Re: OpenSSL is considering a more aggressive EOL policy
#7A 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.
Re: OpenSSL is considering a more aggressive EOL policy
#8The 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.
Re: OpenSSL is considering a more aggressive EOL policy
#9A 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 (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.
Re: OpenSSL is considering a more aggressive EOL policy
#10The headline, while matching the article, is misleading. This is about OpenSSL's EOL policy, not an EOL for OpenSSL itself.
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.