Live data from Hacker News

Ask HN: Negative OpenSSL sentiments

news.ycombinator.com

41–50 of 52 posts

Re: Ask HN: Negative OpenSSL sentiments

#41
post #23

"mistakes will continue to be made in code" Not gravely if professional testing of the open source code is put into place. Yes it might be expensive but critical Internet libraries that serve a variety of purposes—with names such as Apache, Ruby, PHP, SSH and Linux– would benefit greatly from deep assessments.

Someone realized this a long time ago, and the Linux kernel is already being audited and tested, with regression tests, etc (see the Linux Testing Project). OpenSSH is also generally well regarded because of the same scrutiny.

Someone else made the comment that security can't be an afterthought, so PHP will probably never be auditable, and most people agree it should be dropped in favor of more robust technologies anyway.

Re: Ask HN: Negative OpenSSL sentiments

#42

I've tried not to be too critical of the developers, but I do understand where some of the negativity comes from. Have you ever tried to use OpenSSL, as a developer? It's kind of a crufty mess. * Initialization is even more complicated than the security needs dictate, and so is everything afterward. * The internal abstractions are leaky, e.g. requiring a poll for read before you can write (and vice versa), because of…

OpenSSL is one of those codebases that isn't so much measured in WTFs per minute as minutes to CANNOT UNSEE.

However, for practical use everything else seems to be worse (with the possible exception of PolarSSL, which is sadly probably screwed politically by its licensing).

So, yeah, it's software, and therefore hateful. And I'm infinitely grateful to the developers anyway because, well, it exists, and damned if I have the time, motivation or competency to do any better.

The asshattery is, I agree, understandable. But it's still asshattery.

Re: Ask HN: Negative OpenSSL sentiments

#43

It's somewhat understandable; OpenSSL is a bit of a mess, and the two most recent occurrences have made me seriously think about learning more crypto in order to write a replacement, ala DJB (cf sendmail/qmail, bind/tinydns). Of course, while I think I wouldn't make any buffer overflow errors (I've got tools and training for that), I'm fairly certain I wouldn't get the crypto right the first time, and probably not th…

I'd be fascinated to see what the results would be if the problem was tackled by somebody who was both capable of getting the crypto right, and willing to use DJB's substdio or any of the various equivalents.

Re: Ask HN: Negative OpenSSL sentiments

#44
post #38

I've tried not to be too critical of the developers, but I do understand where some of the negativity comes from. Have you ever tried to use OpenSSL, as a developer? It's kind of a crufty mess. * Initialization is even more complicated than the security needs dictate, and so is everything afterward. * The internal abstractions are leaky, e.g. requiring a poll for read before you can write (and vice versa), because of…

Isn't documentation something that can be fixed by people as they use OpenSSL?

Documentation is in some ways harder to fix than code; you can fix what the code does, but documenting the intent can only be done by the author or someone involved in the original design.

Re: Ask HN: Negative OpenSSL sentiments

#45
>What we need is

None of the stuff you mention. Openssl is not in need of funding, or more eyes. Even the developers say more money won't fix it. Openssl is broken. It is so far gone that it is not salvageable. It needs replaced, not funded.

Re: Ask HN: Negative OpenSSL sentiments

#46
post #11
post #7

Couldn't agree more. Heuristic to use when someone is bashing someone else's code: Have you contributed (money, code, docs) to the project? If the answer is no: person lacking skin in the game - irrelevant (even harmful) armchair comment.

I don't think that's very good reasoning. Bad software is bad software regardless of who has funded it, who has committed code to it, or who has written its documentation. One does not have to be a contributor to that software in order to analyze it and make a judgment regarding its quality.

I think by 'bashing' oskarth was trying to refer to the part where people are criticising not just the code but at least implicitly also the developers.

One can say 'this code is terrible' without also saying 'How idiotic was the committer'.

Re: Ask HN: Negative OpenSSL sentiments

#47
post #43

It's somewhat understandable; OpenSSL is a bit of a mess, and the two most recent occurrences have made me seriously think about learning more crypto in order to write a replacement, ala DJB (cf sendmail/qmail, bind/tinydns). Of course, while I think I wouldn't make any buffer overflow errors (I've got tools and training for that), I'm fairly certain I wouldn't get the crypto right the first time, and probably not th…

I'd be fascinated to see what the results would be if the problem was tackled by somebody who was both capable of getting the crypto right, and willing to use DJB's substdio or any of the various equivalents.

DJB already wrote his own crypto library, NaCL:

http://nacl.cr.yp.to/

It's been packaged up as libsodium:

https://github.com/jedisct1/libsodium

That said, even DJB doesn't trust himself to write bug-free C code:

http://cr.yp.to/qmail/qmailsec-20071101.pdf

Re: Ask HN: Negative OpenSSL sentiments

#48
"Mistakes were made" and "cut them a break" only goes so far. If your neighbor loans you a car that's great. If your neighbor loans you a car and it's a little bit dirty and grungy, that's not a big deal. If your neighbor loans you a car AND IT GIVES YOU CANCER because the metal is made out of radioactive waste, that's a bad thing. A very, very bad thing.

Right now we are almost at that state. It is honestly nearly that bad. Having a false sense of security can easily be worse than having no security at all.

Re: Ask HN: Negative OpenSSL sentiments

#49
Critical sentiments can be useful when they are of the form: “X didn't work, we moved to Y because blah blah and we did it by yada yada”.

Whenever something needs fixing in TLS we always hear about the OpenSSL patch first, so it seems like the project is healthy. I think this (and some of the context around the Debian incident) points out that we should be looking at replacements focused on implementation safety (bluishcoder's ATS-based demonstration looks like the right direction), good defaults, and a simpler API (one that also doesn't give so much leeway to shoot oneself in the foot through configurability).

Re: Ask HN: Negative OpenSSL sentiments

#50
post #30
post #19

Earlier quoted context omitted.

Did you personally take part in the fighting in WWII? If not, how can you say that Hitler was a bad person? (Deliberately invoking Godwin, because that's the level of logic I'm responding to :P )

Although I recognize that your intent is a reductio ad absurdum of the parent's point of view. you should also recognize that this comment draws a parallel between the volunteer devs of OpenSSL and Hitler.

It does seem like some members of the community nearly see it this way, considering their reactions.
Post reply on HN