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

111–120 of 142 posts

Re: OpenSSL Security Advisory

#111

Post by ams6110 »

judemelancon wrote: post #91
ajross wrote: post #83

Earlier quoted context omitted.

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…

I have trouble understanding what they're meant to signify, yes. I am a regular human with finite intellect; I admit it. To actually comprehend this function requires storing those 14 names in short-term memory, reading through the over 300 lines of remaining code, filling in bits of the meaning of those names as they become clear, and only then reading the code again with that mental map. That's the case where none…

I don't know the codebase, but if for example, there's a project wide standard or convention for what the variable j means, then it could be OK. Or at least not as bad as it first appears. Not all code has to be written for an assumed stranger on the street trying to sight-read it.

Re: OpenSSL Security Advisory

#112

Post by rgj »

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…

And the coding style doesn't exactly avoid errors as well.

"Do not unnecessarily use braces around a single statement:

    if (condition)
        action();
and

    if (condition)
        do_this();
    else
        do_that();
"

Didn't people learn from the goto fail bug ? http://embeddedgurus.com/barr-code/2014/03/apples-gotofail-s...

Re: OpenSSL Security Advisory

#113

Post by ams6110 »

glass- wrote: post #96
jerf wrote: post #63

Earlier quoted context omitted.

Probably because once you wrap your code around one SSL stack it's hard to migrate it to another. So you stick to the one you use first. OpenSSL, for instance, isn't just an SSL library... since C has no standardized "stream" functionality, it's a whole big generic streaming library with pluggable modules for various streams and the ability to write your own... once you're stuck to that you can get stuck pretty hard…

LibreSSL is a drop-in replacement for OpenSSL.

Well that's the intention... is it really in practice? They have deliberately removed a lot of support for rare architectures and features.

Distributions such as CentOS/RHEL which are focused on stability are not going to replace OpenSSL in any existing releases.

Re: OpenSSL Security Advisory

#114

Post by alricb »

ams6110 wrote: post #111
judemelancon wrote: post #91

Earlier quoted context omitted.

I have trouble understanding what they're meant to signify, yes. I am a regular human with finite intellect; I admit it. To actually comprehend this function requires storing those 14 names in short-term memory, reading through the over 300 lines of remaining code, filling in bits of the meaning of those names as they become clear, and only then reading the code again with that mental map. That's the case where none…

I don't know the codebase, but if for example, there's a project wide standard or convention for what the variable j means, then it could be OK. Or at least not as bad as it first appears. Not all code has to be written for an assumed stranger on the street trying to sight-read it.

This is OpenSSL we're talking aboot here.

Re: OpenSSL Security Advisory

#115

Post by kyberias »

bch wrote: post #102
mzs wrote: post #76

Earlier quoted context omitted.

"Patch provided by the BoringSSL project." This is an example of them doing better. A bug was found, reported to them, and they responded quickly giving advanced notice too.

This is also an example of open source working, in general. Bug found in one project, applied to other.

I think the same could happen in closed source projects as well.

Re: OpenSSL Security Advisory

#116

Post by nadams »

ForHackernews wrote: post #84
s1lver wrote: post #81

Earlier quoted context omitted.

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

I once worked with some Linux admins who told me that SSH public key authentication wasn't secure.

Re: OpenSSL Security Advisory

#117

Post by zdw »

nly wrote: post #73
Arnt wrote: post #67

Earlier quoted context omitted.

But Jon Postel didn't mean what people now think he did. His famous principle is about border cases, when the spec is vague, handwavy or thought by some to be vague. It's not about the other cases. Remember that Jon Postel was the RFC editor. He didn't want anyone to ignore the RFCs, he wanted the RFCs to be readable and pleasant, and he wanted implementers to do the right thing when when an RFC erred on the side of…

Here's an example of the problem with that though: a mailing[0] by someone in February of this year asking if there's a formal grammar for the DNS zone (master) file format. This is a format that was first loosely specified in a RFC almost 32 years ago and there still isn't a rigorous definition. BIND now specifies a defacto interpretation with lots of liberal "treat this as a warning" options[1] and new gTLDs regist…

There's a reason why I try to use the tinydns zonefile format (http://cr.yp.to/djbdns/tinydns-data.html) whenever I can.

It's so much simpler to use, and less problematic.

Re: OpenSSL Security Advisory

#119

Post by richm44 »

glass- wrote: post #96
jerf wrote: post #63

Earlier quoted context omitted.

Probably because once you wrap your code around one SSL stack it's hard to migrate it to another. So you stick to the one you use first. OpenSSL, for instance, isn't just an SSL library... since C has no standardized "stream" functionality, it's a whole big generic streaming library with pluggable modules for various streams and the ability to write your own... once you're stuck to that you can get stuck pretty hard…

LibreSSL is a drop-in replacement for OpenSSL.

It /was/ a drop in replacement for a single point in time but it isn't if you make use of any of the recent improvements openssl has added. For example auto selection of DH/ECDH primes and curves.

Note that recently a big clean up of the openssl codebase has taken place so openssl master no longer exposes the internals of structs etc. meaning it's both more auditable and more maintainable. This code is not yet released however.

Re: OpenSSL Security Advisory

#120

Post by richm44 »

Alupis wrote: post #94
ctz wrote: post #59

Earlier quoted context omitted.

The bit you don't cover is where you repeatedly submit patches (in my case, for example, to fix documentation and improve testing) which are ignored.

This is not true anymore. At the time, OpenSSL had really a single maintainer, and was only receiving $2,000 a year in "donations". Not exactly something to keep someone working full time on the project with. A lot of that has now changed with the Core Infrastructure Initiative.

I do agree the situation is now better, but personally I've still found contributing to be a lot harder than it should be even for trivial fixes.
Post reply on HN