[juanbyrge]

Code quality and hygiene mean absolutely nothing if you have a large number of academic types who use OpenSSL as the dumping ground for their pet research projects, that are enabled by default, of course.

Also, OpenSSL supports all kinds of ancient esoteric platforms that are essentially unused, yet were kept in the code base for sentimental reasons.

The real metric they should be looking at is the number of features/platforms/LOC removed from the project. Less code = less surface areas for exploits.

[asveikau]

I think the multiplatform support is an interesting criticism but misunderstood.

I happened to be reading some OpenSSL code around the time of heartbleed and statically linking some of it in a project. I found a lot of the portability ifdefs were poorly done even for the standards of the 90s. It wasn't portability itself that was the issue, it was actual quality and in many cases the wrong abstractions in place.

One example that sticks out in my memory... There was a logger that had a Win32 ifdef. If you ran on Win32 it fed log messages directly to MessageBox(). Unless it detected the current process was an NT service, in that case it used another logging mechanism without asking. It wasn't actually "windows portability" or "windows support". The whole thing wasn't appropriate for a library. It could have had a mechanism to give the log lines to the application as a C string and be done with it. Instead, it was mixing of library layer stuff and application layer stuff, or just ordinary library bloat.

The other huge example I recall was compliance with older configurations that were pre-C99. C99 is much more universal now vs 20 years ago, although there are a few things Microsoft still doesn't support. But again, a bunch of these things seemed to be handled with ifdefs at the call site, rather than put in a proper compatibility layer that only an older configuration gets.

It does seem that in the years since then, cruft has been removed not only in forks but also in the upstream project.

[Gibbon1]

An aside my feeling about Microsoft and their lack of C99 support is the community was inexplicably too nice to them. As well as compilers defaulting to C89 instead of the latest.

Also as someone that has a code base that targets a dozen different pieces of hardware ifdef madness is a strong indication that your program architexture is broken. Sometimes it's unavoidable but you should think of ifdef's as another name for FIXME.

[asveikau]

Microsoft has gotten a bit better at it after many years of zero progress. Vs2010 introduced stdint and stdbool. Vs2015 finally allowed mixed declarations and code. I think the most lacking piece lately is the named struct member initializers.

[jdsully]

Almost all the progress made was necessary to support modern C++ standards, although it is nice they enabled it in the C compiler. They haven't added any C only features in a very long time.

[Mountain_Skies]

During a code review we found recently written Go code using SHA1, which has been functionally obsolete since 2005. It's a bit baffling why Google even included it in Go or at the very least didn't make it throw up a bunch of warnings to only use it for very special edge cases related to backward compatibility.

The developer didn't know what algorithm to pick so he just went with one at random, assuming it was ok since it was in the library. How many other security vulnerabilities are out there due to similar circumstances? It's a bit troubling.

[userbinator]

Git still uses SHA1, as does a bunch of other not-really-security-critical things (mostly as a much stronger checksum against corruption rather than malice.)

If the purpose of the hash in that code was security-critical and compromised by malicious collisions, it would definitely be a problem. Otherwise it shouldn't be --- and jumping at things without understanding the nuance is precisely one of the problems with the "security industry" today.

[dcow]

Exactly. At a former employer, we had the VA once symbol dump a library we were using and try to knock us since it included a symbol for a sha1 function. The hash was used for a non-security-critical component of web-sockets as a simple collision resistant session identifier. Good luck explaining this to the same people that tried to knock us for using a function that is deprecated in the windows libc implementation for not length-checking its parameters but has always worked correctly on Linux and macOS, citing the windows developer portal as documentation for why our mobile Android and iOS apps were cause for worry.

[chasil]

Unused? Ha ha, good one. Our VAX will never die.

    $ set def [.openssl]
    $ run openssl
    WARNING: can't open config file: SSLROOT: 
    [000000]openssl.cnf
    OpenSSL> version
    OpenSSL 1.0.0r 19 Mar 2015
    OpenSSL> quit
    $

[oblio]

So that makes, what, 2 of you? For widely used libraries and programs "no one" should be approximated to "less than 0.01% of users".

[userbinator]

The platform-specific stuff is not where most of the bugs have been found, so your assertion is misguided. Portability is one of the greatest strengths "keeping crypto freely accessible for all" and the fact that e.g. with a suitable C89 compiler I can create a binary that will run on an original 8088 IBM PC and perform SHA256 or AES should not be underestimated.

To a first approximation, crypto is pure maths. The rest can be taken care of by the standard C library.

[caf]

Not only that, but the testing on oddball platforms can be a good way to reveal latent bugs.

[duxup]

"dumping ground for their pet research projects, that are enabled by default, of course"

How does that work? How does anyone even approve it if it isn't going to be used?

Admittedly I'm out of the loop as far as contributing to such projects, maybe letting that stuff in is the norm?

[throw0101a]

> How does that work? How does anyone even approve it if it isn't going to be used?

How do you know it won't be used if it isn't put in in the first place?

[duxup]

What kind of things are we talking about that someone would add to OpenSSL outside of its core functions?

[jcranmer]

Extensions to SSL, such as the SSL heartbeat extension (RFC 6520)... the one where the Heartbleed bug was found in. Other cipher suites would be another example.

The criticism here is that OpenSSL wasn't particularly choosy in which features of SSL (or other crypto in general) that it supported; it supported all of them, even if they were of more questionable utility.

[tptacek]

The perils of being the reference implementation.