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.
No, generally there is no respect for the complexity of libraries. There is a reason why library authors themselves are reluctant to do many or broad changes.
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.
Your tangent into right wing politics aside, everybody absolutely has a right to modify openssl and run it modified, it's in the license. Doesn't make every instance of it a good idea, but that right exists.
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.