On 15.09.2017 18:21, Thiago Macieira wrote:
On Friday, 15 September 2017 00:31:36 PDT Sami Nurmenniemi wrote:
I think we'll just have to accept blocking for the devices without
hwrng. I don't know if we really support any such devices. If we do and
boot time is essential for those, we'll have to figure out some way
(probably saving entropy over reboot).
And that would be a non-Qt job. I wasn't worried about Qt on real devices
because I don't expect it to be run early enough to matter. On VMs, that's
another story, and if you don't trust your undercloud-provided /dev/hwrng, why
are you using that cloud? (Though I'll say there's an Intel team working on
figuring out how a VM can get trust from the actual hardware, skipping the
hypervisor trust)
We have made some safety critical customer demos where fast boot time of
Qt framework is essential. It was demoing boot time of 1.2s for a Qt
application to start after powering on the device. I suppose that demo
(and real safety critical use cases) is going to have problems with the
QRandomGenerator even with hwrng in use.
Anyway, I've read the entire Python thread to figure out what their conclusion
was. Turns out, after spending hours reading everything, the bug ends without
a conclusion. It must have been concluded, but it's not recorded in the bug
report!
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
