No More Security Fixes For Older OpenSSL Branches (csoonline.com) 60
itwbennett writes: The OpenSSL Software Foundation has released new patches for the popular open-source cryptographic library, but for two of its older branches, OpenSSL 1.0.0t and 0.9.8zh, they will likely be the last security updates because support for these these two branches will end on Dec. 31. Previous research has shown that many companies using in-house built software keep poor records of which library versions their developers used in which of their applications. 'This makes it very likely that some systems and applications with OpenSSL 0.9.8 and 1.0.0 will never be updated, leaving them exposed to any critical vulnerabilities found in the library in the future,' writes Lucian Constantin.
Re: (Score:3)
Re: (Score:2)
I seriously can't understand why developers keep on using OpenSSL.
FIPS 140-2 compliance.
Re: This is awful and irresponsible. (Score:1)
It's also very good.
Re: (Score:2)
My first thought: "Well, that's going to be just great for their reputation."
Still on Windows 95? 1.0.0 was replaced in 1998 (Score:4, Informative)
1.0.0 which is no longer being updated, was replaced by 1.0.1 in December of 1998. In other words, if you want to be secure, use a version from 1998 or later.
That seems pretty reasonable to me.
Re: Still on Windows 95? 1.0.0 was replaced in 199 (Score:4, Informative)
misread. 1.0.1 (supported) is March 2012 (Score:3)
You're correct, I read something wrong. 1.0.1, which is supported, is from March 2012.
Re: (Score:2)
Oh, I understand. I just think it will negatively impact their reputation. Call it a hunch but ... No, if I type it then normal behaviors might not be followed. ;-) So, yeah, I suspect it will be taken as a negative and that's not really something they need right now. For better or worse, justifiable or not, that's just what's probably going to happen - and probably by people who don't actually know any better.
Re: misread. 1.0.1 (supported) is March 2012 (Score:2)
The obvious (to me) solution is to make prior versions of OpenSSL compatibility wrappers for the current version. Thus, the new code is used (and is therefore more secure) but the old interface exists for applications outside the control of users.
Re: misread. 1.0.1 (supported) is March 2012 (Score:3)
The key point of which, current is compatible with (Score:2)
The key phrase in all of that may be:
> starting with 1.0.0 all 1.0.x releases have been binary compatible.
Meaning that the current version 1.0.2 is an exact drop-in replacement for the 2010 version 1.0.0 - no wrapper is needed. For software from before 1.0.0 (2010), it will need to be recompiled.
Re: (Score:1)
Break the library? Eh? It's not broken.
Just - when an exploit for it gets found, why don't [i]you[/i] fix it? Or better yet, migrate your projects to the supported branch and continue on receiving free updates.
Re:This is awful and irresponsible. (Score:4, Insightful)
Re: (Score:2)
Re: This is awful and irresponsible. (Score:3)
Re: This is awful and irresponsible. (Score:2)
Of course since Java is almost painfully backwardly compatible, it's just as easy for them to move to a Java 8 runtime as to move to a new Java 6 runtime. Those who don't care about security probably haven't been keeping up with patches in the first place.
Re: (Score:2)
Java (the language) is compatible, but it's my understanding that going from Java 6 to Java 7 some of the package names changed (and some packages were dropped). I could be wrong (I haven't developed in Java since 6) but didn't all of the com.sun packages change to com.oracle or something like that?
Re: (Score:2)
didn't all of the com.sun packages change to com.oracle or something like that?
Yes, but you really shouldn't be using those packages anyway. They're non-standard, internal implementation details.
Re: (Score:2)
Well, sort of. This will be somewhat more interesting than usual, because Apple ships 0.9.8* on OS X and iOS. They were unable to upgrade, because it would break binary compatibility with shipping apps. So the question is whether Apple will back-port patches to their implementation manually or remove OpenS
Re: If you are so outraged (Score:2)
Re: (Score:2)
Yeah. I wrote that deprecation blurb for Apple back when 10.7 came out. It has probably been long enough that they can safely drop it, but if they do, it will still be interesting to see how many developers ignored the deprecation. :-)
Re: (Score:1)
If you're going to break the fucking library by declaring it insecure trash for life, break the library. Make it crash hard when it's used. The problem software will percolate up to the users' attention.
And how will that work? Oh yeah, like this:
"Hey, the new version of OpenSSL 0.98 breaks our build! Fuck it. Stick with what we have. It works."
Because no matter what you do, the last version that works is the last version that works. Putting out a deliberately broken version won't change that.
Re: (Score:2)
You really don't understand this, do you?
This is typical when something goes end-of-life (EOL). They're not "breaking" it, they're just not supporting it anymore. Even if they did "break" it users would have to update to the broken and version and when it didn't work they'd just move back to the previous version.
What's irresponsible is users not knowing (or caring) about what third party software they're using and whether it's secure or not.
Re: (Score:2)
Serious question - why should any software vendor have to support anything 8-10 years old for free? Why not do what Microsoft does and just patch the crypto libs along with the OS on a regular cycle.
As someone who has done quality assurance - testing these patches has to be an absolute nightmare.
Re: (Score:2)
"Serious question - why should any software vendor have to support anything 8-10 years old for free"
Because they introduced the bugs for free to start with.
Re: (Score:2)
"Free is irrelevant in this case, as is who introduced the bugs."
Free is as irrelevant in this case as in the one above. Who introduced the bugs is not at all irrelevant. Someone can either be proud of his trade and then not allow software oneself produced having bugs or someone can indulge himself and say "you know what? I consider this to be deprecated".
"In fact this might be a problem if the authors have not announced deprecation"
In my book, deprecated means "no more features will be added to this bran
In other news... (Score:1)
https://marc.info/?l=openbsd-t... [marc.info]
So one bug was in code deemed dodgy in external peer-review and the other was in code not really needed. Right.
Re: OpenWRT (Score:2)
Re: OpenWRT (Score:2)
I'd have thought they'd be using LibreSSL, the fork OpenBSD developers made of OpenSSL.
Re: (Score:2)
LibreSSL is still growing, and is limited in what platforms (OS and arch) that it supports.
False. MS doesn't patch Win95. Or XP (Score:2)
Your assertion is false.
The 1.0.1 branch from 1998 will still get patches. Openssl versions earlier than 1998 will not. So it's precisely the same as if Microsoft said they're only going to release patches for Windows98 and above, and stop supporting Windows 95. I'm pretty sure they've done exactly that. And both companies dropped support for much newer versions as well. ONLY open source would still be releasing patches for an 18-year old version of the software.
Re: False. MS doesn't patch Win95. Or XP (Score:2)
yes it was. Here's the changelog (Score:2)
> OpenSSL wasn't even around in 1998.
Here's the OpenSSL changelog, including changes in 1998 releases such as 0.9.8g. The 0.9.x.y branch lasted a long time.
https://www.openssl.org/news/c... [openssl.org]
As you said , 1.0.1 wasn't released until 2012.
Re: yes it was. Here's the changelog (Score:2)
They do this all the time (Score:2)
That's why Microsoft has so much abandonware and so many defunct branches of software. Same with Apple. Difference is, anyone can revive those OpenSSL branches, whereas Microsoft destroys source code that could be subject to future lawsuits.
Zork (Score:2)
It resulted in lawsuits, such as DRDOS, being extended over decades, and many potentially exciting businesses being driven into bankruptcy.
To this day, it results in WINE incompatibilities where none should exist. This is a genuine problem.
Far as Windows 3.11 is concerned, lots of systems you really don't want failing (such as control systems for hydroelectric dams and nuclear reactors) use ancient versions of operating systems (NT 3.x, for example) because it's too dangerous to reimplement the control soft
Re: (Score:2)
Re: (Score:2)
Apple and Microsoft both do this, what are you talking about?
No worries (Score:2)
Re: No worries (Score:3)
Re: (Score:1)
I think OpenSSL might be a special case here. By an odd coincidence I was watching the OpenBSD devs talks on LibreSSL yesterday and they actually covered backporting fixes from OpenSSL.
http://www.openbsd.org/papers/eurobsdcon2014-libressl.html [openbsd.org] - See the section title "apply the brakes". (for those interested, the slides here are from this video: https://www.youtube.com/watch?v=WFMYeMNCcSY [youtube.com])
My overall impression is that the OpenSSL developers don't really make peoples lives easy when it comes to backport
Re: (Score:2)
Nobody's done that properly for Python 2.7 SSL libraries, for instances.
They just disabled certain functions which break a lot of, say, Python programs auto-updating from Github SSL sites. Fixes for several bits of software affected by this (e.g. Emscripten) just say "modify the source program, modify your python library to skip those bits, or put in massive function overrides for those functions to make it always enable a certain option".
Getting Emscripten to install/update/pull down new libraries when yo