The parent article is targeted not just at people writing shell scripts, but people writing libraries that are implementing cryptographic processes, generating keys, etc.: the article even goes so far as to state that people generating long-term keys should also use /dev/urandom over /dev/random.

Now, as a developer, you write a library or daemon, or some other piece of userland code. You do not know on what operating systems or at what point in the bootup process it will be used. You know it works fine if and only if /dev/urandom has been seeded, and so use /dev/urandom.

However, apparently, people install your daemon at boot and generate the keys at boot, on VMs that are created often from scratch. There's nothing inherently wrong with these computers: they have entropy sources, they just don't have any entropy at boot, the referenced "boot-time entropy hole".

Your code now "doesn't work". It isn't that it crashes, it doesn't block: in fact there's no way at all to tell that anything wrong happened, except that some point a long time later someone finds out that every encryption key you generated from it is from a limited, guessable, "weak" subset.

The argument here seems to be that this is the fault of the person who built the computer. Honestly, I somewhat agree. However, let's imagine the real-world conversation that would happen if the developer of this library/daemon actually stated this limitation up-front in their README somewhere.

README: "Note: this program only works correctly if the entropy pool is adequately seeded before running it."

User: "Wow, ok; can you tell me if Ubuntu is up to the challenge?"

Developer: "No. It isn't that simple: the system doesn't block boot for the entropy pool to fill, so whether your system is setup correctly is up to whether entropy fills fast enough; your chosen distribution is one aspect of this, but we will also need to look at what kinds of hardware you have attached and external factors such as whether the network you are using gets much traffic."

User: "Seriously? Is there some simple test I can run on my computer that would let me determine if my system is broken?"

Developer: "No. These are complex factors that are difficult to verify statically. Your attempts to analyze the data yourself will also almost certainly come long after the entropy pool has already received the critical mass required for /dev/urandom to become secure. Your attempting to run the test would also affect a lot of the entropy sources directly, including network and input."

User: "But it is possible if I spent more time on it?"

Developer: "Well, sure: there was a paper published where some researchers instrumented the kernel attempting to analyze these issues. They were able to determine that OpenSSH on RedHat was generating its host keys only just barely after the entropy cutoff on standard desktop computers. You could make similar patches to your kernel and attempt to see whether your usage seems safe."

User: "That sounds ludicrous... was there really no way for you to code around this?"

Developer: "Oh, sure, we could use /dev/random; but then sometimes the program would block under heavy load when it really didn't need to; rather than just changing to /dev/urandom, some of our users were responding by hardcoding the randomness of our program entirely, defeating all of the security in our system. To protect these people we decided to switch to /dev/urandom ourselves."

User: "Couldn't you have made that an option, choosing the most generally secure option by default, but providing /dev/urandom as a sane alternative 'when using under heavy load', thereby guiding people who have this issue to not do something insane? Maybe you could read /dev/random once when your program starts, to get the blocking behavior, and then switch to /dev/urandom for later repeated use?"

Developer: "No. This is apparently a black and white issue, and we have to decide emphatically whether /dev/random should always be used or should never be used. The idea that this might be a complex issue that requires nuance in thought and might have to be decided on a case by case basis, or for which there might be some solution that involves working around the issues with one by using the other momentarily, should not occur to us."

[edit:] (So, it sounds like maybe the correct solution at this point is that the user seeds /dev/urandom themselves using /dev/random. Of course, this solution only works if the user is smart enough to do this and has access to do it, neither of which are likely true on many Android devices. The developer could do this for the user, but that's back into the "nuance" discussion. Instead of being so emphatic that "/dev/random should never be used" people should be advocating developers use actual solutions, potentially "workarounds", to the problems that come up in real-world deployment :/.)