

OpenSSL is considering a more aggressive EOL policy - cnst
http://lists.freebsd.org/pipermail/freebsd-security/2014-June/007784.html

======
vertex-four
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.

~~~
laumars
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
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
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
> 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.

------
laumars
_> "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

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

~~~
dang
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.

~~~
cnst
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!

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

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

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

~~~
mrweasel
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.

------
azdle
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'.

~~~
laumars
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.

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

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

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

