> arc4random() works in a chroot, but the new ssp routines in Glibc > need /dev/?random in the chroot (using arc4random() with ssp will pull > too much code into ld.so). So since we need /dev/?random for ssp, other > stuff like mkstemp() can depend on the device in the chroot too.
No problem, just `cp -a` them. You need /dev/null in chroot anyway. > I added patches yesterday and today to make Bash use /dev/urandom for > $RANDOM, [EMAIL PROTECTED]:~$ RANDOM=1 [EMAIL PROTECTED]:~$ echo $RANDOM 16838 [EMAIL PROTECTED]:~$ echo $RANDOM 5758 [EMAIL PROTECTED]:~$ RANDOM=2 [EMAIL PROTECTED]:~$ echo $RANDOM 908 [EMAIL PROTECTED]:~$ RANDOM=1 [EMAIL PROTECTED]:~$ echo $RANDOM 16838 [EMAIL PROTECTED]:~$ echo $RANDOM 5758 So throw the patch away, you are screwing things. It's documented and must behave like this. If you want to use it with arc4random(), you must ensure that once it's seeded by a number, old behavior returns. > All this is heavy use of /dev/urandom, especially ssp, so /dev/erandom > becomes more important. I've tried ssp using /dev/urandom with random > number gathering daemon, and while the kernel entropy pool never runs > empty, the rngd uses 50% cpu to keep up with demand. So /dev/erandom is > the only thing that makes sense, and I can't really blame Glibc and > others from using cheap entropy (blame the kernel developers for not > providing it with aes). Well... gettimeofday() is +/- safe. On smp systems it's IMO unpredictable unless you block (n - 1) cores with 100% load. It's safe enough for temporary files of non-critical applications (no, compiler is not critical in this case). -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
