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.
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.