bind-9.9.5 regression test error

[Christoph Moench-Tegeder]

## Doug Barton (dougb at dougbarton.us):

> >> If you don't have enough random bits on your system to run these simple
> >> tests, your /dev/random is seriously underpopulated, and likely a
> >> security risk. You should definitely not put BIND in production compiled
> >> with the option you mention above.
> >
> > Our build/test environment is not our production environment.
> 
> Then what's the point of running the tests? If your test environment 
> isn't closely mirroring your production environment you're mostly just 
> wasting time.

Verifiying patches, for example. It's in the nature of our product
(think appliance) that we cannot build on the target directly and
testing there is somewhat tedious, so we want to get as much coverage
as possible before moving to the target.
Thinking of it, there're a lot of "production" environments lacking
the tools for running tests, or where mucking with the ip addresses
on the loopback interface is not possible, so you end up running your
tests in a mock environment.

> > Further, the ideas about "random numbers for practical purposes"
> > have shifted a bit. In short, you don't really need "high real entropy",
> > but a stream of numbers *unpredictable to the adversary*.
> 
> Yes, I'm quite familiar with those thoughts, and have some degree of 
> sympathy with them. You will hopefully have noted that I didn't 
> recommend hooking up a hardware based source of high-quality entropy to 
> every name server. What I actually recommended was that Linux systems 
> run a low-impact, freely available piece of software that helps to stir 
> the entropy pool so that /dev/random can produce sufficient PRNG bits 
> without blocking. That's more than adequate for nearly all uses, unless 
> you're actually doing work which requires a high-quality RNG.

I agree tieh that (and still believe that just for running "make test"
in a mock environment /dev/urandom is still good enough).

> > In fact, on systems like FreeBSD you never get to see the "entropy"
> > directly, you only get the output of a PRNG (yarrow in this case),
> > which is periodically reseeded with "real entropy".
> 
> Funny you should mention FreeBSD's Yarrow, as I was peripherally 
> involved in its initial implementation. :)  I'm not sure what point 
> you're trying to make by mentioning that "you never get to see the 
> 'entropy' directly" though. That's not only a feature, it's a 
> fundamental part of the design.

The point is "the amount of entropy in some pool is not a measure of
the quality of the random numbers". The blocking behaviour of linux'
/dev/random looks like a relict from times where that point was not
universally accepted.

But now this is becoming a discussion abount random numbers and their
generation - I think this sould be moved off-list?

Regards,
Christoph

-- 
Spare Space