> > Anecdocally, libbsd's arc4random is not necessarily secure. IIUC the > > code isn't as glaringly dangerous as g_rand*, but it will seed with only > > the time and PID if other sources fail. I think we should avoid > > conflating BSDs' arc4randoms with libbsd's. > > > > https://github.com/libressl-portable/portable/tree/master/m4 > has autoconf checks with an OS whitelist for arc4random. > It would be nice to keep things similar to these so that > updates can be merged across from newer versions easily.
I disagree. libressl is making extremely conservative decisions, to protect the way that libressl is (1) used and (2) seen. The same model is not applicable to everything. If you create an ecosystem where arc4random continues to be treated like a failure (which is not), then you are not creating the conditions for adoption of its, so get ready for more use of RAND_pseudo_bytes() and RAND_status(), more manual use of gettimeofday() seeding. More opening of /dev/urandom with sloppy failure cases. Especially with no handling of out-of-file descriptor conditions. Make sure the failovers you offer to them handle that, ok? Essentially, downstreams are finally in a position to educate upstreams that libc libraries are missing something important, and that it is no longer possible to do the right thing because the fundamentals are missing. POSIX has no way of getting a good random number. If the opportunity to educate is not used at the time when software is being ported downstream, well then you are part of the problem.
