Live data from Hacker News

OpenSSL is written by monkeys (2009)

peereboom.us

151–160 of 188 posts

Re: OpenSSL is written by monkeys (2009)

#151
I am a bit reluctant to repeat myself, but I can't see any mentioning of the sheer volume of code. It's more than 300.000 lines of code in the .c files of the official tarball.

My experience with code grown beyond >10⁵ LoC is that it forces you to monkey-patch around any bugs (or even features for that matter). Surely there's a Potterson's Law or something that describes the situation.

In short: it's not the monkeys (quality), it's the volume of code.

(Of course now we're getting in a chicken-egg situation.)

Re: OpenSSL is written by monkeys (2009)

#152
post #61
post #19

I've done quite a bit of programming with the OpenSSL library and this article is only scratching the surface of the awfulness. Documentation is horrible to non-existent, you really do need to go spelunking into the source to figure out how things work, and the code really is that horrible. The worst thing is that error reporting is not consistent - sometimes -1 means error, other times 0 means error, other times 0 m…

O.K. This is probably a stupid question but if it was apparent to many that the code of OpenSSL was horrible why people kept using it and nobody tried to re-factor it? How it is possible that such a popular and critical piece of opensource software survived the years without a complete face-lift and nobody wrote thorogh documentation?

Most people don't bother - they just start using a different one: gnutls, nss, etc.

Yes, reports of awful code quality in OpenSSL are not exaggerated.

Re: OpenSSL is written by monkeys (2009)

#153

Article raises a good point. Seeing this repeated 50+ times made me cringe though if ((req = X509_REQ_new()) == NULL) ERROR_OUT(ERR_SSL, done); seriously.. also, writing new code and not using Rust, or D, or even C++. WTFs like the above are par for the course when you're writing in a 40 year old language without any features of modern low-level languages.

I don't think writing bad code is a reflection on the language. You can write rubbish code in any language.

Re: OpenSSL is written by monkeys (2009)

#154
post #61
post #19

I've done quite a bit of programming with the OpenSSL library and this article is only scratching the surface of the awfulness. Documentation is horrible to non-existent, you really do need to go spelunking into the source to figure out how things work, and the code really is that horrible. The worst thing is that error reporting is not consistent - sometimes -1 means error, other times 0 means error, other times 0 m…

O.K. This is probably a stupid question but if it was apparent to many that the code of OpenSSL was horrible why people kept using it and nobody tried to re-factor it? How it is possible that such a popular and critical piece of opensource software survived the years without a complete face-lift and nobody wrote thorogh documentation?

Because the core idea about the "bazaar" thing that ESR evangelized is BS.

Most people don't have the time or care -- even if they know how to do it. The big push for open source was when companies where sponsoring its development with a lot more paid developers than today (companies from IBM and SUN to RedHat, Corel, Novell, Eazel, VA Linux -- remember them? The bubbliest IPO in history).

That can happen not only for highly specialized code like OpenSSL (which even fewer people can understand), but even for very common and widespread application level code, including projects that one would assume would attract many people.

Gtk, for example, the GUI kit used in Gnome, has just one developer really working on it (I know, cause he complained). Compare that to the 20+ GUI teams companies like Apple and Microsoft, with dedicated technical writers for the documentation et al.

Re: OpenSSL is written by monkeys (2009)

#155
post #149

Earlier quoted context omitted.

It is really difficult to refactor such things at the public API layer once they are widely adopted by 3rd party projects. Take the aforementioned error return inconsistencies -- how do you possibly deal with refactoring that for consistency when so many other projects are consuming OpenSSL as a library? You're trading one big problem (new clients are likely to get error return handling wrong) with another (if you mo…

> It is really difficult to refactor such things at the public API layer once they are widely adopted by 3rd party projects. But how did it ever get so widely adopted, if it's so hard to use? And even if it is widely adopted, that still shouldn't stop anyone from forking it and fixing all the problems.

So why didn't you?

Re: OpenSSL is written by monkeys (2009)

#156
post #61

Earlier quoted context omitted.

O.K. This is probably a stupid question but if it was apparent to many that the code of OpenSSL was horrible why people kept using it and nobody tried to re-factor it? How it is possible that such a popular and critical piece of opensource software survived the years without a complete face-lift and nobody wrote thorogh documentation?

1. Other libraries do exist -- NSS, GnuTLS, etc. 2. Do you have time for a rewrite? What makes you think anyone else would? 3. The (generally correct) mindset is don't implement your own crypto . This is particularly true of something like TLS, which is complicated and has subtle requirements that are easy to screw up. Unfortunately, this means that even people who have time are discouraged from doing an OpenSSL rewr…

Historically GnuTLS had even more security trouble than OpenSSL (like that bug where it was trusting a self signed root certificate even if not in the certificate store that went undetected for years).

And NSS is pretty light on the server code IIRC...

In my past as professional code auditor, I've seen OpenSSL shipped with products quite a bit, and in 99% of the cases it was openssl the command line tool that was used to access the functionality because yes, the API is that bad and confusing that people would rather pipe to an executable that use library calls...

Re: OpenSSL is written by monkeys (2009)

#157
post #124

Earlier quoted context omitted.

1. Other libraries do exist -- NSS, GnuTLS, etc. 2. Do you have time for a rewrite? What makes you think anyone else would? 3. The (generally correct) mindset is don't implement your own crypto . This is particularly true of something like TLS, which is complicated and has subtle requirements that are easy to screw up. Unfortunately, this means that even people who have time are discouraged from doing an OpenSSL rewr…

What I don't understand is why there aren't companies around that have an interest in improving this software and pay ~1-5 people ~1 million to rewrite it in a year.

Because companies are cheapskates nowadays.

Back in the Linux bubble days (1997-early 2000s), lots of companies employed full time people to work on all kinds of stuff, not just profitable company project, but also needed infrastructure. Even front end projects, like Nautilus and Evolution were created by full paid teams.

Re: OpenSSL is written by monkeys (2009)

#158
post #125

Earlier quoted context omitted.

In case anyone's curious, here's a link to the libsecurity_ssl source (albeit not totally up to date — latest version is pre-"goto fail;" fix): http://opensource.apple.com/source/Security/Security-55471/l...

I guess we see how well that worked out for them.

Compared to what?

You are aware that GnuTLS had a very similar "goto" style verification bypass bug, and that OpenSSL has had several flaws and broken stuff discovered, including the major recent "Heartbleed Bug".

Re: OpenSSL is written by monkeys (2009)

#159
post #146

Having worked with OpenSSL on only one occasion. I figured something was up when they have a function named SHA1_Update and SHA_Update that has the exact same signature and creates different outputs. A library designed by incompetents.

SHA_Update is for the SHA-0 hash, and SHA1_Update is for the SHA-1 hash, so it's hardly completely illogical. The main issue here, is that people that don't know the difference between SHA-0 and SHA-1 should likely not be in charge of computing hashes by themselves. Crypto requires some expertise or it goes awry very fast, but then the educational system is producing plenty people with good crypto knowledge, it's hardly the niche it was only 20 years ago.

Also SHA-0 support is left out if OPENSSL_NO_SHA0 is defined, which must at last be the case in the FIPS version of the library, the one your want to use for regulation reasons in many cases...

Re: OpenSSL is written by monkeys (2009)

#160
post #155
post #149

Earlier quoted context omitted.

> It is really difficult to refactor such things at the public API layer once they are widely adopted by 3rd party projects. But how did it ever get so widely adopted, if it's so hard to use? And even if it is widely adopted, that still shouldn't stop anyone from forking it and fixing all the problems.

So why didn't you?

It's not something I work on. But clearly a lot of other people do. And I have some trouble believing that all those people building stuff on top of OpenSSL don't care about security.

Look, if this was about something fairly inconsequential, like a library for a game or a blog or something, sure, use some badly maintained, badly documented, inconsistent library. But when you care enough about security to use SSL, surely you care enough to use something that's put together in such a way that you can be sure it does what you think it does? Bad documentation and inconsistent error handling in a security package sound like an unbelievably dangerous idea. And if it's really an unmaintainable mess, like everybody says, then how can bugs possibly be fixed? How easy would it be for the NSA to insert some crucial vulnerability into the code base?

Security, moreso than anything else in computer science, needs to be clear, transparent, understandable, well documented and well maintained. If it's not, mistakes will be made and security will be compromised.

Post reply on HN