From owner-freebsd-arch Tue Feb 27 13:52: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 1B95137B71B; Tue, 27 Feb 2001 13:52:03 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id QAA12138; Tue, 27 Feb 2001 16:50:42 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200102271952.f1RJqSs35224@cwsys.cwsent.com> References: <200102271952.f1RJqSs35224@cwsys.cwsent.com> Date: Tue, 27 Feb 2001 16:50:40 -0500 To: Cy Schubert - ITSD Open Systems Group From: Garance A Drosihn Subject: Re: rand(3) (was Re: cvs commit: ports/astro/xglobe/files patch-random) Cc: Kris Kennaway , Terry Lambert , "Jacques A. Vidrine" , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:51 AM -0800 2/27/01, Cy Schubert wrote: ><... putting my manager's hat on> >... Could we not implement a solution similar to malloc()'s >/etc/malloc.conf and MALLOC_OPTIONS? The default could be set to >rand() calling random(), while setting the appropriate option would >revert to the "old" behaviour. Or, #ifdef. Either way we satisfy >both camps. I suspect that is unworkable. If there is some security issue where it is important that rand = random, then you won't want that security diluted if someone setting an environment variable... (I might set the environment variable because of my simulation written in fortran, and have it then effect some other program which I am also running, where it is a security issue). Something #ifdef-ish might be workable to everyone's satisfaction. > >Ideally, rand() is insecure and should be removed or should call >random(), protecting clueless developers from themselves and more >importantly protecting clueless end users from clueless developers. > >We three choices: > >1. Status quo. >2. A more secure rand(). >3. A hybrid. Well, I've been trying to sit here and think of a good hybrid solution, but for the last hour I've been interrupted every 2 minutes with something or another. Perhaps some warning at compile time, except I can't quite think of how to do that. I can imagine something silly at link time, such that references to 'rand' generate an warning like mktemp. People who want statistically-random numbers would avoid that by changing the source so they get random instead of rand. People who want the historical rand behavior would '#define randold rand' (where randold is a duplicate of rand), thus avoiding the direct reference to rand at load time. Anything where calling 'rand' is a security risk is hopefully something that is compiled often enough that this would quickly address that issue. I can't stop today's interruptions long enough to tell if I really like the above idea, but at first blush it sounds plausible. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message