Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenSSL Security Advisory

openssl.org

Post reply on HN
Print view View original

81–90 of 142 posts

Re: OpenSSL Security Advisory

#81

Post by s1lver »

Alupis wrote: post #71
drzaiusapelord wrote: post #38

Earlier quoted context omitted.

Christ, what a mess of a project. They inserted this after their big promise to do better after heartbleed? No wonder distros take their time moving to a new version. I really hope one of the alternative SSL libraries get picked up by the major distros. This is embarrassing, especially for those of us who have to justify FOSS in our environment. LibreSSL looks promising. Hopefully competition will mean better outcome…

You can't be serious here? Bugs are introduced into software all the time. It's a sign of active development. It's not the number of bugs that matters, or even the fact that new bugs get introduced over time - rather it's the severity of the bugs, how rapidly the bugs are realized, and ultimately how fast they are dealt with. In this case, it appears to have been a pretty rapid resolution - ie. about 1 month from it…

The OpenBSD guys have little to no prior crypto experience? Can you prove this?

Re: OpenSSL Security Advisory

#82

Post by Arnt »

nly wrote: post #75
Arnt wrote: post #74

Earlier quoted context omitted.

BTW there's a reason for that. The IETF decided (it must be a couple of decades ago) to restrict itself to matters of the internet. Things like file formats are thus out of scope for RFCs. There have been exceptions, RFC5952 is a good example and I know at least two others, but by and large RFCs are about the internet now, not about file formats or other worthy subjects.

RFC7159? It even recommends a file extension.

That's a perfect example: Publishable as an RFC because the format is used in many APIs on the general internet, but also says a little about a local matter, in this case the file names.

Is the rule a bit messy? Yes it is!

Re: OpenSSL Security Advisory

#83

Post by ajross »

judemelancon wrote: post #79

I am hardly astonished that a 319-line function that opens by declaring x, xtmp, xtmp2, chain_ss, bad_chain, param, depth, i, ok, num, j, retry, cb, and sktmp variables had a bug. Before someone provides the standard "submit a patch" retort, I'll note that the variable naming is in full compliance with https://www.openssl.org/about/codingstyle.txt even if the function length isn't. A quick sample of other files sugge…

You seriously have trouble reading "i", "j", "param" and "num"? Hell, "ok", "depth" and "retry" are already in your English-language dictionary!

I'll grant that having variables named with "tmp" is confusing out of context, I guess. But if you're trying to start a Java-style war over this stuff, just recognize that most of the world has moved on and views names like those as perfectly fine when used within standard idioms.

Re: OpenSSL Security Advisory

#84

Post by ForHackernews »

s1lver wrote: post #81
Alupis wrote: post #71

Earlier quoted context omitted.

You can't be serious here? Bugs are introduced into software all the time. It's a sign of active development. It's not the number of bugs that matters, or even the fact that new bugs get introduced over time - rather it's the severity of the bugs, how rapidly the bugs are realized, and ultimately how fast they are dealt with. In this case, it appears to have been a pretty rapid resolution - ie. about 1 month from it…

The OpenBSD guys have little to no prior crypto experience? Can you prove this?

I mean, OpenSSH is such a piece of buggy garbage... /s

Re: OpenSSL Security Advisory

#85

Post by d_theorist »

KayEss wrote: post #70
d_theorist wrote: post #61

Earlier quoted context omitted.

>And even then, for this attack to be meaningful you'd need to have active MITM between the server and PyPI or rubygems Yeah. Which is pretty much the thing (or one of the things anyway) that TLS is supposed to prevent! >These are activities usually triggered by developers or administrators, not by web servers remotely and they have to do with a web application, not a web server. Some strange distinctions. A server r…

This should only be the case for the build server that creates the packages that get installed on production.

Maybe that's how you do it, but I guarantee that there are loads of production webservers out there grabbing stuff from all over the web and building it in situ.

Re: OpenSSL Security Advisory

#86

Post by binarycrusader »

aninteger wrote: post #43

Why has the adoption of alternative SSL software been so low. We have libressl, boringssl, something from Amazon? Very few Linux distributions seem interested in shipping alternative SSL software.

Because, quite frankly, many FOSS components are not that actively maintained, and all of the alternatives either raise licensing considerations, were not intended for use by general projects, or are not significantly mature yet.

Many projects have also invested heavily into optimizing the performance of OpenSSL itself or the use of its interfaces.

You can't sprinkle "magic SSL dust" over these components and just start using an alternative. In some cases, significant, non-trivial changes would be required to change which library is used.

The reality is, as fast as OpenSSL development is moving now, it remains the better option for a lot of projects because of the significant investments already being made and concerns I mentioned earlier.

Re: OpenSSL Security Advisory

#89

Post by ectoplasm »

ajross wrote: post #83
judemelancon wrote: post #79

I am hardly astonished that a 319-line function that opens by declaring x, xtmp, xtmp2, chain_ss, bad_chain, param, depth, i, ok, num, j, retry, cb, and sktmp variables had a bug. Before someone provides the standard "submit a patch" retort, I'll note that the variable naming is in full compliance with https://www.openssl.org/about/codingstyle.txt even if the function length isn't. A quick sample of other files sugge…

You seriously have trouble reading "i", "j", "param" and "num"? Hell, "ok", "depth" and "retry" are already in your English-language dictionary! I'll grant that having variables named with "tmp" is confusing out of context, I guess. But if you're trying to start a Java-style war over this stuff, just recognize that most of the world has moved on and views names like those as perfectly fine when used within standard i…

The use of shorthand names like that is a strong indication that the variables don't need to be live for ~319 lines. If you reduce the live range of your variables, you reduce the complexity of your function. Less complex functions are less likely to have bugs and are easier to diagnose when they do.

Re: OpenSSL Security Advisory

#90

Post by tedunangst »

s1lver wrote: post #81
Alupis wrote: post #71

Earlier quoted context omitted.

You can't be serious here? Bugs are introduced into software all the time. It's a sign of active development. It's not the number of bugs that matters, or even the fact that new bugs get introduced over time - rather it's the severity of the bugs, how rapidly the bugs are realized, and ultimately how fast they are dealt with. In this case, it appears to have been a pretty rapid resolution - ie. about 1 month from it…

The OpenBSD guys have little to no prior crypto experience? Can you prove this?

It is narrowly true that the libressl devs are not cryptographers, but that's also quite misleading. Lots of bugs, like say... this one, are not crypto related.
Post reply on HN