3 ms·

This piqued my curiosity and it seems you really didn't do it justice there. Rather than patch out the actual use of the uninitialized memory (always a good thi

This piqued my curiosity and it seems you really didn't do it justice there. Rather than patch out the actual use of the uninitialized memory (always a good thing to do) IIUC instead the core part of the function that mixes new randomness in was patched out. Like the tire was flat so you went ahead and just chopped off the entire axle with an angle grinder because who needs 4 wheels anyway.

amiga386 4mo ago
Agreed, but you also have to look at it from a packager's point of view. Here is the actual patch: https://salsa.debian.org/debian/openssl/-/commit/8f27a7dc022e95ab7274628715f22207235f8e36 https://salsa.debian.org/debian/openssl/-/commit/8f27a7dc022... Notice how clean and small a patch it is? (ignore that, in making it clean and small, it has "chopped off the entire axle" as you say) And here's what led to making that patch: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516 These links contain specific people's names, but the important thing is not to blame those people specifically, because this failure came from the whole Debian community and its values. A community that eagerly went looking for, e.g. valgrind correctness. A community that thought it knew better than upstream, and didn't check their changes with them. A community that values neat patches that close bugs, without thinking of the wider ramifications. The community has learnt a lot of lessons since 2008, and is now much more aware of how packager meddling could cause security flaws. (You could also single out the OpenSSL developers for their faults too, but this particular error was on Debian)
- yjftsjthsd-h 4mo ago
  A community that thought it knew better than upstream, and didn't check their changes with them. It is my recollection that they both tried to run it by upstream, and believed that they had successfully done so. That may still be an error, but not the kind of fundamental flaw you imply.
- xorcist 4mo ago
  > thought it knew better than upstream, and didn't check their changes with them That is not fair. Debian generally works close with upstream, since most Debian Developers are free software enthusiasts in some way. The patch in question made it to the OpenSSL mailing list and received only encouragement. The only problem, as it turns out, was that less than a handful people knew those parts of OpenSSL well enough, and they didn't have time to hang around the mailing list. The real development of OpenSSL happened behind closed doors. A lot of people learned from that incident. It is wrong to blame it on the Debian Developer who tried to clean up the code and went to the OpenSSL development mailing list for help. It is far from clear that uninitialized memory helps randomness at all, unless you are intimately familiar with the history behind those lines.

amiga386 4mo ago

Agreed, but you also have to look at it from a packager's point of view. Here is the actual patch: https://salsa.debian.org/debian/openssl/-/commit/8f27a7dc022e95ab7274628715f22207235f8e36 https://salsa.debian.org/debian/openssl/-/commit/8f27a7dc022... Notice how clean and small a patch it is? (ignore that, in making it clean and small, it has "chopped off the entire axle" as you say) And here's what led to making that patch: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516 These links contain specific people's names, but the important thing is not to blame those people specifically, because this failure came from the whole Debian community and its values. A community that eagerly went looking for, e.g. valgrind correctness. A community that thought it knew better than upstream, and didn't check their changes with them. A community that values neat patches that close bugs, without thinking of the wider ramifications. The community has learnt a lot of lessons since 2008, and is now much more aware of how packager meddling could cause security flaws. (You could also single out the OpenSSL developers for their faults too, but this particular error was on Debian)

yjftsjthsd-h 4mo ago
A community that thought it knew better than upstream, and didn't check their changes with them. It is my recollection that they both tried to run it by upstream, and believed that they had successfully done so. That may still be an error, but not the kind of fundamental flaw you imply.
xorcist 4mo ago
> thought it knew better than upstream, and didn't check their changes with them That is not fair. Debian generally works close with upstream, since most Debian Developers are free software enthusiasts in some way. The patch in question made it to the OpenSSL mailing list and received only encouragement. The only problem, as it turns out, was that less than a handful people knew those parts of OpenSSL well enough, and they didn't have time to hang around the mailing list. The real development of OpenSSL happened behind closed doors. A lot of people learned from that incident. It is wrong to blame it on the Debian Developer who tried to clean up the code and went to the OpenSSL development mailing list for help. It is far from clear that uninitialized memory helps randomness at all, unless you are intimately familiar with the history behind those lines.