3 ms·
> Obviously I'm missing something here For a start, there's a long tail of migrating all useful software to /dev/sane_random. Moreover, there's a risk new soft
by orra 5y ago
> Obviously I'm missing something here
For a start, there's a long tail of migrating all useful software to /dev/sane_random. Moreover, there's a risk new software accidentally uses the old broken /dev/random.
Besides, /dev/sane_random essentially exists; it's just a sysctl called getrandom().
- tptacek 5y agoIt's not that simple; Donenfeld wants to replace the whole LRNG with a new engine that uses simpler, more modern, and more secure/easier-to-analyze cryptography, and one of the roadblocks there is that swapping out the engine risks breaking bugs that userland relies on.
- westurner 5y agoShouldn't it be easier than a kernel parameter to compare the performance of specific applications that relied upon the current behaviors; at least for a major rev or two?
- vilhelm_s 5y agoWhat kind of bugs are visible to userland? I would have thought a random number device would be the least likely thing to have upgrade problems like that: applications should not be able to assume anything at all since the output is literally random...
- hansel_der 5y ago> Moreover, there's a risk new software accidentally uses the old broken /dev/random. but that risk is at 100% NOW, how is it not worth reducing it?
- orra 5y agoI fully agree.