Forthcoming OpenSSL release announced | Hacker News Reader

Forthcoming OpenSSL release announced

mta.openssl.org

77 pointsRygu19 comments

Reading the tea leaves on this one early we can probably assume there's a good chance the high vulnerability does not affect libressl, which forked before the 1.0.2 codebase. We'll find out about the low.

Did they communicate these issues via a backchannel to LibreSSL and BoringSSL yet?

Will this be the first High issue since 0.9.8 and 1.0.0 stopped getting fixes? It'll be interesting to see how that plays out.

what's the procedure to update in debian? the offical repo will be updated immediatly or what?

I'd imagine a security release will be cut as soon as a diff is available.

From my limited understanding, the update would be pushed through the security.debian.org repository ASAP, which should be configured by default.

I wonder what the 0.9.8 EOL means for squeeze-lts. Does the Debian LTS team just backport all applicable 1.0.1 patches? Isn't this a little risky? They might not have an intimate understanding of the opaque codebase.

What about Wheezy and Jessie after support for 1.0.1 ends on 31 December?

The EOL on squeeze-lts is next month -- listed as February 2016 on https://wiki.debian.org/LTS.

It's unclear if that's the beginning or end of the month.

This is why long-term support is less cool than it might first appear.

Definitely. But even without LTS, Jessie would be without upstream SSL patches starting 2017. Stretch might not even be released by then. And I wouldn't call the Debian release cycle unreasonably slow.

You get problems like this, but with the amount of overlap in time the different versions provide, with regards to security updates, I'd say its far from unreasonable that one should be able to move over to the next version before stuff like this becomes a problem.

Remind me how long LTS gives you to upgrade to a new version.

If you're waiting until the very end of LTS support to upgrade, you're doing it wrong anyways.

What is the range of severities? Is 'high' the highest?

For OpenSSL, I'm not sure. This highlights something I was going to mention, though. I wish each project would stop coming up with its own scale and just use, for example, CVE scores or some other "standard" by which all these vulnerabilities can be compared.

“Critical” is the highest. A link to the list of severities is smack in the middle of the message.

> Please see the following page for further details of severity levels: https://www.openssl.org/policies/secpolicy.html

Thanks! I should get my sight checked!

So rhe Openssl devs are the new carpenters? They should specify an exact time instead, so that I can upgrade at a known time without having block the entire afternoon. They could just as well tell us it would be available at 5pm.

Assume it will be available at 1700 UTC then.

There was a time in the not so distant past when we didn't even get a "heads up" like this so, personally, I am appreciative of the advance notice.

That means that my 10k company users will have systems vulnerable for between 0 and 4 hour longer than necessary. That is less than optimal. Really, why do thy even give a 4 hour window for when it will be released?

I wonder which exploit mitigation countermeasure was "bugfixed" in the new release?

Reply on news.ycombinator.com