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
