Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 25 Jul 2022 01:55:40 +0200
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
To:     Paul Eggert <eggert@cs.ucla.edu>
Cc:     libc-alpha@sourceware.org, linux-crypto@vger.kernel.org
Subject: Re: arc4random - are you sure we want these?
Message-ID: <Yt3b/HOguK9NFgCd@zx2c4.com>
References: <Ytwg8YEJn+76h5g9@zx2c4.com>
 <555f2208-6a04-8c3c-ea52-41ad02b33b0c@cs.ucla.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <555f2208-6a04-8c3c-ea52-41ad02b33b0c@cs.ucla.edu>
Precedence: bulk

Hi Paul,

Sorry I missed your reply earlier. I'm not a subscriber so I missed this
as I somehow fell out of the CC.

On Sat, Jul 23, 2022 at 05:18:05PM +0000, Paul Eggert wrote:
> On 7/23/22 09:25, Jason A. Donenfeld via Libc-alpha wrote:
> > it's hard to recommend that anybody really use these functions.
> > Just keep using getrandom(2), which has mostly favorable semantics.
> 
> Yes, that's what I plan to do in GNU projects like Coreutils and Emacs.
> 
> Although I don't recommend arc4random, I suppose it was added for 
> source-code compatibility with the BSDs (I wasn't involved in the decision).

Source code compatibility isn't exactly a bad goal. But according to
Adhemerval you don't plan on this being a secure thing -- hence
mentioning as such in the documentation as he mentioned -- so it seems
like a maybe-okay goal gone bad. But, anyway, if the goal is just basic
source code compatibility, back it with simple calls to getrandom() to
start, and if later there are performance issues (big if!), we can look
into vDSO tricks and such to speed that up. There's no need to add a
whole new huge fraught mechanism for that.

> > is there anyway that glibc can *not*  do this, or has that
> > ship fully sailed
> 
> It hasn't fully sailed since we haven't done a release.

Well that's good. I'd recommend just backing it out until it can be done
in a way that glibc developers feel comfortable calling safe (and others
too, of course, but at the very least you don't want to start out making
something you feel the need to warn about in the documentation).

> That's a bit harsh. Coreutils still has its own random number generator 
> because it needed to be portable to a bunch of platforms and there was 
> no standard. Eventually we'll rip it out but there's no rush. Having 
> written much of that code I can reliably assert that it was not fun.

I'm happy to help with this if you need. I recently cleaned up some
stuff similar sounding in systemd for their uses; random-util.c there
might be of interest.

Jason