> Date: Sun, 17 Jan 2021 10:43:41 +0200 > From: Andreas Gustafsson <g...@gson.org> > > For the Nth time: if the problem is solved at the system integration > level, there will be no blocking and therefore no need for your > proposed change.
But conversely, if the problem is solved at the system integration level, there will be no need for blocking and therefore no harm from the proposed change. So what I would like to hear is how causing applications to silently hang indefinitely helps to solve the problem. The experience I've seen over a year where the unblocking criterion is, for the first time, actually meaningful -- and not just `eh, a few keystrokes or network packets oughta be ``random enough'', right?' -- is that applications silently hanging indefinitely confuses people, leads them to think NetBSD is broken, and/or gets them frustrated at the stupid paternalistic entropy system. (`Why don't you just put ``dd if=/dev/urandom of=/dev/random bs=32 count=1'' in the man page, or do it in rc to fix the issue automatically?') > I for one did feel trapped by this, but it's easily fixed. I also > think the UI is too complicated and intimidating in general and > needs to be simplified. But I still think sysinst is the best place > to do this, and certainly more user friendly than being dropped into > single user mode on boot. You and I may be perfectly happy with understanding and addressing the technical details at installation time, but I'm not willing to impose the same burden on everyone around me. There's a tension between several things here: 1. Minimizing burden on users -- which means avoiding asking deeply technical questions they may not be competent to answer like `what is a string you just picked uniformly at random from 2^256 possibilities?', especially when captive while running sysinst where there's little opportunity to explore and read man pages at leisure. 2. Working on a large variety of hardware -- which includes hardware that does not have a HWRNG. 3. Guaranteeing security or failing closed -- which means suddenly ceasing to work for deeply technical reasons. We can't satisfy all three at the same time. You would like to do (2) and (3); someone whose machines all have HWRNGs might only care for (1) and (3); others who are just trying to get things done on private networks will pick (1) and (2). So I'm trying to simultaneously do a few things to improve the situation for everyone: - improve silent out-of-the-box entropy on as many systems as possible (more HWRNG drivers; hardclock samples as makeshift ring oscillator; also considering spinlock contention as another one) - give users unobtrusive feedback about their own security (concise warnings on console, daily security report, maybe motd) so they are alerted to the problem with a reference to further reading about how to address it - provide the option for security-critical systems to fail closed at boot with a clear indication of why (entropy=check/wait in rc.conf) - potentially log the keys that may need to be regenerated to assist the operator in fixing the problem in case of, e.g., installation by writing a live image only accessible via ssh and - keep the people who aren't security nerds happy enough that they aren't tempted to go around creating workarounds that make things worse just to get done what they were trying to do (like suppress _all_ feedback with the dd hack) But it's becoming less and less clear to me what value there is to making applications hang indefinitely in this system -- not just as an isolated matter of a single component failing closed, but how it helps the whole system.
