> Date: Sat, 16 Jan 2021 14:34:47 +0200 > From: Andreas Gustafsson <g...@gson.org> > > Even if the unblocking criteria of Linux and FreeBSD are questionable, > they still provide more security than your proposal which amounts to > having extremely strict criteria but then completely ignoring.
This is not accurate. The strict criterion is still available _for system integration_, which is where the problem needs to be solved anyway, just like other security measures like securelevel and fetch_pkg_vulnerabilities. The effect of making _applications_ just hang like this is that it confuses everyone involved and breaks builds, because in practical terms nothing is going to unblock them until the operator plugs in a USB HWRNG or equivalent and it is not helpful to ask every application to include logic that meaningfully prompts the user to do so. > > Such an application, like a Python program in the middle of just doing > > `import multiprocessing', is not in a position to remedy the situation > > or even usefully alert an operator to the problem. > > Which is why we should deal with the issue by creating an entropy seed > at the time of installation or first boot. We already do this, and it incorporates any entropy obtained during the installation process. This will include keystroke timings during installation, and hundreds of samples of a makeshift ring oscillator on each boot, if the hardclock timer interrupt and CPU cycle counter or system timecounter are driven by independent clocks. Of course, it is hard to tell for sure whether this is the case from MI software -- so it remains best effort, without a confidently positive assessment. > To start with, we should re-enable the code Martin already added to > sysinst to prompt the user for missing entropy at install time, and we > should continue to work on making it easier to use. It's not just a prompt -- it will make users feel _trapped_ and hate the whole thing, in an installer that already has too many mandatory incomprehensible questions. As a matter of user experience, a mandatory question like this that gets in the way of doing anything else is a dead end. Security features that paternalistically prevent people from getting things done will drive them to workarounds that defeat the security. > We should also provide more entropy sources with conservative but > nonzero estimates to make those prompts increasingly rare. I would be happy to consider literature with conservative assessments of these entropy sources if you have any references! But a year after drafting the changes, nobody has provided such references, and many people have run into practical problems that the system in place is not conducive to fixing. That's why, based on the experience, I'm trying a different approach: provide clear hints and nudges where there may be a problem, without making anyone feel trapped and resentful toward the issue, and without causing apparently unrelated things to break on principle.