I don't see how this is political. In that link he presents actual problems that have arisen from non-blocking versions. I'd call that a technical justification.

I don't necessarily agree with his justification, but that's also a difference in technical opinion. The only way I'd fault him is if I can come up with a an approach that addresses his concerns yet he still refuses to accept them.

Full disclosure: I've actually interacted with him on a few occasions. IMO calling him risk/change-averse would be an understatement, which partly explains this stance. While at times frustrating for us, this is exactly the quality you want in someone maintaining such a critical part of the kernel.

I suspected that “politics” was going to end up being the answer to my question. Simply because this seems to be a very contentious issue, even if it doesn’t need to be.

Edit: Thanks for the link!

And what is the current state of /dev/urandom on Linux? Does it finally block on cold start with too little entropy? If it does, then effectively everybody can finally just use /dev/urandom, if I understand it correctly?

If it's still not blocking, it seems that still the best thing to do is using getrandom( ..., 0 )?

Why should it be made non-blocking? If you want a large string with little entropy just use /dev/urandom. The political/dogmatic argument is that is should be made non-blocking. The process of acquiring entropy in typical computers is definitely blocking.

What does "acquiring entropy" mean here? There is no reason a properly seeded CSPRNG should ever need to block.

I don't think you understand how CSPRNGs work.

Do go on.