Some notable things I learned:
* This affects both OpenSSL and OpenSSH, but the keys are different. I.e. you have a set of vulnerable OpenSSH keys and a set of vulnerable OpenSSL keys. But the key format is the same, yet most of the tools to detect just look for either of these. I found a TLS certificate created with a vulnerable key generated by OpenSSH.
* It was "conventional wisdom" that ECDSA was unaffected because some sources said that OpenSSL version did not support ECDSA. However that was wrong, you can generate ECDSA keys with that old version.
Generally it seems a lot of the detection tools are incomplete. E.g. github seems to block some vulnerable keys, but only a subset.
But here we have all the proponents of "distributions should never do any patch (and thus leave all the security issues open)". But they live in a fantasy world where all upstream authors reply within 3 minutes, fix issues within 30 minutes and of course backport the fix.
Which says a lot. With better communication, from everyone involved, this wouldn't have happened the way it did.
Lessons from the Debian/OpenSSL Fiasco - https://news.ycombinator.com/item?id=196035 - May 2008 (2 comments)
Decades ago someone wrote an empty loop to do "something" and it looped for a fixed number of times. No one knew why. But seemed that loop depended upon the frequency of the CPU. It was kind of a sleep (I forgot most of the details) that was needed for some reason. When the system was upgraded, things stated breaking.
That statement should be a tattoo on everyone's hand :)
On a DOS PC, a better way to delay would be to count timer interrupts.
date +%s.%N | sha256sum
And it's completely insecure - just guess the time and you know the output.
The reality of a distribution like Debian is that it needs to make patches to code to make software work in a holistic distribution, so a strict "no-patches-allowed" policy just isn't workable. The best you can hope to do is have a policy that requires at least some level of approval from upstream developers on the correctness of the patch. Which is what happened here; the only real failure that could have been avoided on the Debian contributor's was to send the entire patch for review. For all intents and purposes, it does look as if the upstream developers approved the change, and at best you're hoping that a more rigorous, formal process would have caught the fact that the people approving the change were not in fact upstream developers.
From the OpenSSL side, the faults are more legion. On the technical side, the code relied on questionable voodoo magic working correctly (when it was known that it didn't work correctly in at least some circumstances!), and the code was intrinsically confusing. On the social side, there was no clear way for a would-be contributor to identify how to get a patch approved by upstream developers. The postmortem on the OpenSSL side, however, was to point and laugh at the Debian contributor for being an ignorant n00b (it's not linked in the article), denying any fault on their part.
Perhaps it should be no surprise that a couple of years later, OpenSSL would be slammed with Heartbleed, which surfaced much of the same technical issues that the Debian bug did but without any ability to blame anybody else for making the bug. Heartbleed was severe enough to force people to learn some of the lessons they should have learned from the Debian/OpenSSL fiasco.
Debian patches too much and can't be trusted is the lesson I learnt.
They haven't changed their patching policy since so I refuse to use any Debian derivative and advise everyone to do so and stick to distributions which stay as close to vanilla as possible.
Similarly I also think that anything pretending to provide LTS while freezing software versions is misguided and mostly lying to you and you are one incorrectly backported patch away from distaster.
It does. This is partly because of The Debian Guarantee: I think that's why they delivered a castrated version of FFMPEG.
If upstream is deemed non-free, then they should just put the package in non-free, and delete it from main. Mangling upstream so they can squeeze it into main is worse than pointless.
How would you define LTS?
But first the sysadmin culture (which I generally like, but not in this aspect) taught us that anyone can modify anything to make it work for him.
Now the equity culture teaches us that anyone is equal and has a right to do any modifications. Correctness does not matter, and if you insist, you are a class traitor.
Projects that deviate from upstream with this attitude have frequent issues.