It looks like HLFS is the only one using arc4random() under Linux. While looking at how to use arc4random() with Coreutils, I started to think maybe using OpenSSL's RAND_pseudo_bytes() is a more portable idea.
Pretty much every Linux distribution includes OpenSSL, so patching Glibc's mktemp(), etc, for OpenSSL would probably be more widely used and tested. The quality is pretty much the same. For HLFS, RAND_pseudo_bytes() can be patched to use /dev/erandom to conserve entropy, but RAND_pseudo_bytes() would be much more likely to be used by other distros, so there's better real-world testing of it, and feedback. arc4random() is a safe and secure prng, but I get no feedback about it. Using RAND_pseudo_bytes() would have the affect of removing cryptography from Glibc, and using OpenSSL whenever possible, which is the direction I've been going. Using RAND_pseudo_bytes() with mktemp() is a circular dependency between libc and OpenSSL, but this can be overcome with dynamic libraries. It means installing OpenSSL in chapter 5. Opinions/comments? robert
pgpSNAqvRYKvH.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
