Cliff Woolley wrote:
On Mon, 27 May 2002, Ben Laurie wrote:
Hmmm. Well, IMO it should be configurable at runtime, especially since
some other OSes have yet more sources of entropy (/dev/arandom for
example).
Oh good, that matches the patch I've been working on. I'll post it in a
little while. P
On Mon, 27 May 2002, Ben Laurie wrote:
> Hmmm. Well, IMO it should be configurable at runtime, especially since
> some other OSes have yet more sources of entropy (/dev/arandom for
> example).
Oh good, that matches the patch I've been working on. I'll post it in a
little while. PS: is /dev/aran
Cliff Woolley wrote:
On Sun, 26 May 2002, Ben Laurie wrote:
What about a --with-devrandom= option for people who do want to go
the /dev/urandom route?
I'm starting to prefer this option I think.
Surely its configurable anyway? Changing the default strikes me as
something that will bite you if yo
On Sun, 26 May 2002, Ben Laurie wrote:
> > What about a --with-devrandom= option for people who do want to go
> > the /dev/urandom route?
I'm starting to prefer this option I think.
> Surely its configurable anyway? Changing the default strikes me as
> something that will bite you if you aren't
Cliff Woolley wrote:
On Sun, 26 May 2002, Ben Laurie wrote:
3) open /dev/random in non-blocking mode and defer EAGAIN reads
until later (read it at startup; if it would block, try again when
the entropy is actually needed, failing if it isn't ready by then
-- no idea if this would even work).
Cliff Woolley wrote:
On Sun, 26 May 2002, Ben Laurie wrote:
3) open /dev/random in non-blocking mode and defer EAGAIN reads
until later (read it at startup; if it would block, try again when
the entropy is actually needed, failing if it isn't ready by then
-- no idea if this would even work).
On Sun, 26 May 2002, Ben Laurie wrote:
> >>3) open /dev/random in non-blocking mode and defer EAGAIN reads
> >> until later (read it at startup; if it would block, try again when
> >> the entropy is actually needed, failing if it isn't ready by then
> >> -- no idea if this would even work)
Cliff Woolley wrote:
On Wed, 22 May 2002, Aaron Bannert wrote:
On Wed, May 22, 2002 at 08:24:04PM -0700, Justin Erenkrantz wrote:
IIRC, /dev/random is a "better" source of entropy than /dev/urandom
because /dev/random can block waiting for good enough bits gathered
from the system while /dev/urand
On Wed, 22 May 2002, Aaron Bannert wrote:
> On Wed, May 22, 2002 at 08:24:04PM -0700, Justin Erenkrantz wrote:
> > IIRC, /dev/random is a "better" source of entropy than /dev/urandom
> > because /dev/random can block waiting for good enough bits gathered
> > from the system while /dev/urandom must
On Wed, May 22, 2002 at 08:24:04PM -0700, Justin Erenkrantz wrote:
> IIRC, /dev/random is a "better" source of entropy than /dev/urandom
> because /dev/random can block waiting for good enough bits gathered
> from the system while /dev/urandom must always spit out something, so
> its entropy isn't
On Wed, May 22, 2002 at 07:21:18PM -0400, Cliff Woolley wrote:
> My question is this: why does APR's configure.in prefer /dev/random over
> /dev/urandom? I think it should be the other way around:
IIRC, /dev/random is a "better" source of entropy than /dev/urandom
because /dev/random can block wa
On Thu, 23 May 2002, Jie Gao wrote:
> The httpd won't fork and hangs on reading from /dev/random: It never
> returns. Would it be possible to have a runtime conf directive to use
> /dev/urandom instead?
This is probably because of mod_auth_digest, which uses
apr_generate_random_bytes().
My quest
Hi All,
> uname -a
Linux 2.4.18-shuckle #2 Wed May 22 15:52:51 EST 2002 i686 unknown
(Red Hat 7.1, with kernel upgraded from 2.4.17 to 2.4.18. Neither
worked).
Apache 2.0.36 configured with:
./configure \
--prefix=/usr/local/apache2 \
--with-mpm=prefork \
--enable-modules=most \
13 matches
Mail list logo
