From dev-return-9427-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Tue Mar 11 23:52:46 2003 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 22671 invoked by uid 500); 11 Mar 2003 23:52:45 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 22660 invoked from network); 11 Mar 2003 23:52:45 -0000 To: Branko =?utf-8?b?xIxpYmVq?= Cc: Ben Collins-Sussman , Joe Orton , dev@apr.apache.org Subject: Re: apr_generate_random_bytes() blocks forever References: <86llzltu0r.fsf@kepler.ch.collab.net> <20030311213316.GA1427@manyfish.co.uk> <86hea9tr0d.fsf@kepler.ch.collab.net> <3E6E5995.4080606@xbc.nu> Reply-To: kfogel@collab.net Emacs: because extension languages should come with the editor built in. From: Karl Fogel Date: 11 Mar 2003 17:16:23 -0600 In-Reply-To: <3E6E5995.4080606@xbc.nu> Message-ID: <85hea9xznc.fsf@newton.ch.collab.net> Lines: 32 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1.50 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Branko =C4=8Cibej writes: > >Or gstein has suggested that apr_generate_random_bytes() can grow a > >new flag, indicating urandom is preferred. > > That would look weird to APR users on systems that have never heard of > /dev/random and /dev/urandom (several come to mind, all of which use \ > for the path separator). Yeah. Anyway, the question of random vs unrandom is an implementation detail, it doesn't belong in interface. The *real* problem here is the blocking behavior -- which is visible to callers and is appropriate to address in the interface, maybe like this: /** * Generate random bytes. * @param buf Buffer to fill with random bytes * @param length Length of buffer in bytes (becomes apr_size_t in APR 1.= 0) * @param dont_block Disallow a long wait for high-quality random * data, even if doing so lowers the randomness of the result. */ apr_generate_random_bytes(buf, length, dont_block); =20 On systems where blocking is not a problem, the `dont_block' parameter would simply have no effect. But the question is, are there systems where blocking is a problem, but there's nothing we can do about it? If so, dont_block would be a lie on such systems, unless we fell back to some *really* unreliable method like pointer values XOR time of day... I don't know if there are such systems, though. Anyone? -K