
A tale of software maintenance: OpenSSL and EVP_CHECK_DES_KEY - PhantomGremlin
http://marc.info/?l=openbsd-tech&m=144472550016118&w=2
======
ndepoel
Ugh, another example of why conditional compilation is such a bad idea. I
know, I know, sometimes it's inevitable. But if you're going to use it, you'd
better be ready to set up a build farm that regularly compiles your code with
every possible permutation of compiler flags, otherwise your code is
guaranteed to break in unexpected ways.

The LibreSSL solution is the correct one here: if your code is old and unused,
just delete it ffs. The argument that "we might still need it in the future!"
is such a lame one. No you don't, and even if you do it'll be easier to just
rewrite it than to try and make years-old code work in a modern environment.
In the meantime you've only succeeded at cluttering your code with garbage
that has no relevance whatsoever.

~~~
mrweasel
>The LibreSSL solution is the correct one here: if your code is old and
unused, just delete it ffs.

I sort of suspect that the OpenSSL developer just fixed the compilation error,
because it's actually easier than deleting code completely.

------
Beltiras
It's remarkably hard to find any recent discussions if libressl is ready for
production. A comparison on
[https://en.wikipedia.org/wiki/LibreSSL](https://en.wikipedia.org/wiki/LibreSSL)
seems to indicate libressl is less vulnerable.

~~~
epimenov

      /  sw_vers 
      ProductName:	Mac OS X
      ProductVersion:	10.11
      BuildVersion:	15A282a
      /  /usr/bin/ssh -V
      OpenSSH_6.9p1, LibreSSL 2.1.7
    

I guess it is ready for production

~~~
Beltiras
Apple is one vendor and I don't care much for their OS.

------
jb613
2 things:

1) 11 years. The code in question was 11 years old. Another example not to
rely on "given enough eyeballs, all bugs are shallow". 11 freakin years.

2) Security off by default is yet another example indicating how security
receives lower priority - in a library whose main aim is to secure data
transport no less!

It all adds up to security debt - at some point it will be paid.

~~~
tedunangst
Off by default was the correct choice.

------
SFjulie1
A PRNG _debian_ bad? I remember the ssh keys incident years ago (that was
indeed ridiculouts, but shit happens).

But I don't remember any new facts about debian weakening PRNG since.

PS: Ok, I also missed debian infortunately also weakening the openSSL PRNG
until 2008.

~~~
cwmma
The random data that was used to initalize the PRNG was removed as it was
causing a linting error and only the PID was used meaning there were only
32768 (2^15) initial states that the PRNG would be seeded with.

[https://www.schneier.com/blog/archives/2008/05/random_number...](https://www.schneier.com/blog/archives/2008/05/random_number_b.html)

~~~
SFjulie1
Yes I remembered this one, and this resulted in the SSH keys being weakened.
So ... it is the same incident.

OpenBSD could forgot one day. As if 50 core devs pretending to know their jobs
could do better than 10000 devs with tremenduous amounts of guidelines and
administrative rules and a fair amount of political commissars.

Lol. Bureaucracy will always beat amateurs.

~~~
kryptiskt
Weakened? It meant it would only generate a couple of thousand keys, that's
not weakened, that means security was killed completely. And it was in there
for a couple of years. All in all a total fiasco and legendary for very good
reasons.

Trying to paper over it and pretending it was no big deal is the best way to
ensure that similar things will happen again.

------
nickpsecurity
That's a hilarious write-up. The OpenSSL anecdote? Less so. Another dark tale
in the history of software "maintenance" and the C language.

------
raonyguimaraes
"<drops mic; walks off stage>"

Very funny way of writing ... Thank you so much for this :D

