> Linux's /dev/urandom happily gives you not-so-random numbers before the kernel even had the chance to gather entropy. When is that? At system start, booting the computer.
What's generally accepted is that, early during first boot, urandom still produces 'random' data without enough entropy for it to be sufficiently random.
What's a myth is that 'entropy can run out' and somehow a sufficiently seeded CSPRNG needs to block after a few reads while it gathers more entropy.
The problem in these discussions is that one, edge case, but valid concern, becomes a cargo cult of "why you shouldn't use urandom" and introduces a messy anti-pattern.
The cargo cult you are describing is exactly the cargo cult trap you are falling into.
After this script runs, the numbers are back to being cryptographically pseudorandom. Before this script runs, lots of other stuff isn't set up -- no networking, no remote filesystems, possibly not even swap -- so if you're writing code that needs to run there, you hopefully know that the system is in a weird state. And if you're writing something that runs a service that needs secure random numbers that early in the boot process, you're definitely doing something nonstandard and possibly misguided, and it's reasonable for the burden to be on you to take appropriate precautions, or switch to doing something normal.
For normal application developers, who tend to wait until after the network is up to interact with the network, this special case doesn't apply.
Of course, /dev/random would block for ages at that point, so I instead generate the seed on a different machine.
