Eric, I cann’t claim to 100% understand the situation but after glancing trough the logs of the discussions and of the patches the conclusion I came to was this – OpenSSL used supposed randomness of the uninitialized memory as an added source of entropy (interesting hack, but not an example of good coding as such). Valgring caught that problem and the Debian maintainer during a cleanup fixed it. Making such a fix can be considered a preventive step against possible attack vectors by poisoning the uninitialized memory. He took it up to upstream, they did not raise red flags, but did not quite merge the ‘clean up’ patch either. It fell through the cracks.
The problem is that in the same file, in another function all other sources of entropy were being merged into the pool of randomness using exactly the same code line as the one code line flagged by Valgrind. The maintainer assumed that the second code line has a similar function to the first and commented that one as well. AFAIK that also did not show up in the emails to the upstream list.
So we have:
- Upstream using clever hacks that rely on uninitialized memory having some randomness to it
- Upstream using same code and same variable names to describe different things
- Upstream having no comments in the code explaining the two things above
- Maintainer slightly over-generalizing a change
- A bug slipping trough the cracks in the review processes
- Another Debian Developer discovering the bug and recognizing its significance despite all of the above
- Debian project coming out and admitting all of the above and scrambling to get fixes out to its users ASAP
I am impressed by the swift action of the people involved in fixing this. And while I think everyone can find some lesson be learned here, I think this is another good example of free software in action. And I hope that in the aftermath of this we will find ways to prevent this from happening in the future without stifling our progress.