Quotes of the week

Given the goal of sending money to cryptographers, I'm pretty sure we want the answer to be a security-audit nightmare, so let me suggest the following idea. There's SIGWINCH to notify processes about window-size changes, so there should also be a signal for RNG changes, which should be called SIGRINCH, and there should be a different mechanism to address RNG output cloning inside the kernel, and there should be endless papers on Grinch Attacks, including papers that sort of prove security against Grinch Attacks, and deployment of software that's sort of protected against Grinch Attacks, and fear of the bad PR from abandoning anything labeled as protection, because, hey, _maybe_ the protection accomplishes something, and it's not as if anyone is going to be blamed for whatever damage is caused by the systems-level effect of the added complexity.

The relatively recent siphash-based bad random32.c code was added in response to concerns that the prior random32.c was too deterministic. Out of fears that random.c was (at the time) too slow, this code was anonymously contributed by somebody who was likely reusing the alias of long time anonymous contributor George Spelvin. Then out of that emerged a kind of shadow entropy gathering system, with its own tentacles throughout various net code, added willy nilly.

Stop👏making👏crappy👏bespoke👏random👏number👏generators👏.

I'd like to break the catch-22 of "ask for a new driver to be written in rust but the rust support isn't landed" vs "the rust support isn't landed because there aren't enough drivers". It really feels like "release early, release often" is needed here; it's hard to develop against -next. :)