Given one of the comments on Ben's post says they get this bug report so often it's in the faq I have to wonder why they haven't fixed it themselves. It's probably not helping with entropy on many OSes, and it's clearly causing problems on their mailing lists and with vendor patches.
Are they just stubbornly waiting for somebody to submit a patch to the right mailing list? Of course now they've revealed openssl-team I fully expect all dev team discussion to move to a new even more secret list.
Any kind of analysis of “how good is OpenSSL's RNG” would have to reject any contribution from the uninitialized data, because they have no way to guarantee that it's not predictable. Indeed, it is quite likely to be all 0 in many cases.
And indeed, the source code attributes no entropy to the uninitialized data. So there is some recognition of this fact in there already.
The messages from valgrind (and purify and whatever) are not harmless, on the other hand. False positives make it harder to debug programs that use OpenSSL; if things are harder to debug, more bugs survive; if more bugs survive, more security holes survive.
I agree entirely, which makes question even more why they've kept it in their despite it apparently being reported as a bug so often.
You're right about 'harmless' uninitialised reads obscuring real problems, C++ copy constructors are particularly bad for generating these when the original constructor doesn't initialise everything.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
no subject
Are they just stubbornly waiting for somebody to submit a patch to the right mailing list? Of course now they've revealed openssl-team I fully expect all dev team discussion to move to a new even more secret list.
no subject
Any kind of analysis of “how good is OpenSSL's RNG” would have to reject any contribution from the uninitialized data, because they have no way to guarantee that it's not predictable. Indeed, it is quite likely to be all 0 in many cases.
And indeed, the source code attributes no entropy to the uninitialized data. So there is some recognition of this fact in there already.
The messages from valgrind (and purify and whatever) are not harmless, on the other hand. False positives make it harder to debug programs that use OpenSSL; if things are harder to debug, more bugs survive; if more bugs survive, more security holes survive.
no subject
You're right about 'harmless' uninitialised reads obscuring real problems, C++ copy constructors are particularly bad for generating these when the original constructor doesn't initialise everything.