4 ms·

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 suppor

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.

blahber 12y ago
/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.
- vezzy-fnord 12y ago
  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.
laumars 12y ago
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.
- vertex-four 12y ago
  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.
  - laumars 12y ago
    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.
    - vertex-four 12y ago
      > 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.
jrochkind1 12y ago
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.
- laumars 12y ago
  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).
  - jrochkind1 12y ago
    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.
    - vertex-four 12y ago
      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.
      - x0x0 12y ago

blahber 12y ago

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

vezzy-fnord 12y ago
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.

laumars 12y ago

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.

vertex-four 12y ago
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.
- laumars 12y ago
  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.
  - vertex-four 12y ago
    > 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.

jrochkind1 12y ago

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.

laumars 12y ago
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).
- jrochkind1 12y ago
  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.
  - vertex-four 12y ago
    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.
    - x0x0 12y ago