they would do better to start asking who uses what feature, and removing unused ones.
OpenSSL is considering a more aggressive EOL policy
21–28 of 28 posts
Re: OpenSSL is considering a more aggressive EOL policy
#22Reading their lists and applying patches would be more "aggressive".
Even the ability to write proper code would be a more aggressive policy.
Re: OpenSSL is considering a more aggressive EOL policy
#23Earlier quoted context omitted.
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…
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.
Re: OpenSSL is considering a more aggressive EOL policy
#24OpenSSL Devs: yeah, we took our eyes off the entire pitch, sorry, off the ball, yeah, that's it, the ball, and errm, the whole recent security thing is risking the gravy train for side line certified stuff, hence the recent annoucements. Meanwhile LibreSSL is eating their breakfast, lunch, and dinner, just by deleting code alone.
Re: OpenSSL is considering a more aggressive EOL policy
#25Earlier quoted context omitted.
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…
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 w…
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.
Re: OpenSSL is considering a more aggressive EOL policy
#26Earlier quoted context omitted.
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.
Re: OpenSSL is considering a more aggressive EOL policy
#27Earlier quoted context omitted.
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 w…
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.
Re: OpenSSL is considering a more aggressive EOL policy
#28Earlier quoted context omitted.
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.