Talk:Entropy-supplying system calls

Talk

edit

This page is pretty sloppy, and it may be impacting code quality. When judging a function in this area, the characteristics of concern include: 1. cryptographic-use acceptable output 2. gauranteed output, no error cases to worry about (error prone) 3. does not block (forever?), no retry cases to worry about (again, error prone) 4. The comparison with rand()-style functions is embarrasing. What next, a comparison against

  getpid() ^ time(NULL)?  Bad practices don't need flaunting unless mention raises the bar.

Can someone with word skills try to write this page from a different perspective? Like maybe, state-of-the-art gets mention as the main-line primitive, and everything else is given a description as a subset?

The state of the art is: always_returns [buffer] gauranteed_random_value() no_matter_what, including early as possible during bootstrap. Anything else has missed the mark -- a significant trap for programmers who suddenly tries to do cryptography "too early". Most of the designs which don't do this right are concessions to the past. Hopefully the python-near-systemd bug is educational, ie. take general purpose code and put it earlier, and it fails unexpectedly. I'm guess I am saying some people anticipated problems like this and build a better system, and some other people didn't anticipate this or the next 100 problems and failed to build right.