On Wed, Jan 23, 2019 at 04:12:24PM +0000, Thorsten Glaser wrote:
Yes, exactly: it's definitely better for a certain class of hardware, but I'm
honestly just not sure whether any of those are still relevant. (Like, do they
work with current kernels, are they in hardware that's otherwise supported,
etc.?) I'd love to see reports from people who are still using the older
version for functionality that isn't in the newer version to help inform what
My MUA just threw this mail to me in an interesting timing attack (I
deleted the last new mail just when this one came into my INBOX and
before it was sorted under the thread), I didn't read any others in
the thread since Monday yet and will see when I have time for this,
but since you asked:
I use the old rng-tools, with several of the now-unsupported command
line options, reading from /dev/stdin which is the stdout of an SSL
client, in a scenario where I distribute entropy over the network to
multiple boxen.
So, software, not hardware. But rng-tools is needed in order to
• attribute the new entropy to the pool estimate
(even though I use a value of less than 8 bit per byte)
• fill the pool up to the watermark
• do some plausibility checks on the input
as otherwise I could just connect the SSL stdout to /dev/urandom
writingly.
In general, the missing flags are good to use if you have hardware
that produces “some” entropy but not an estimated 8 bit per byte,
for example. Also, slow RNGs; I don’t want to have several hundred
MiB/s traffic from this…
So that's basically just the --rng-entropy argument? If we switch
rng-tools5 to the fork at https://github.com/nhorman/rng-tools there's
already a new entropy-count option to address that. I don't see any good
reason to deploy *new* installs of the rng-tools2 codebase for purely
software reasons.
I’ll respond to the other mails in the thread in time, when I have
the time. Just another data point: rng-tools-debian has an installed
user base in testing and in *buntu (they sync’d it), so renaming it
is out of the question now. The package description should make it
clear that rng-tools5 should be preferred to most, but the -debian
is historically true (it’s the one with “all the new options hmh
wrote for Debian”, as opposed to the “latest upstream gkernel” one).
It's been in testing for a matter of days, so I'm skeptical that this is
a real concern. (And it's called *testing* for a reason.) Renaming the
package and adding a rng-tools-debian transition package would make the
matter moot (though I think it would be silly).
Again, calling this rng-tools-debian IMO makes an already confusing set
of packages even worse. (And honestly, this is kind of thing that should
be sorted out when a package is ITP'd and discussed, not done and then
declared a fait accompli.)
--
Michael Stone
