> chacha adds entropy periodically and folds it in. You need entropy in the chroot.
If that's the case then the fix will not be as simple as I envisioned it. Still, the point stands that LibreSSL should allow you to initialize the PRNG once, before you chroot, so that you can use the PRNG safely once inside the chroot. This could be accomplished by keeping a file descriptor to /dev/urandom open.
"If that's the case?" - Didn't you read the code? :) Sounds like you would prefer no stirring of any new entropy after you chroot... Looks to me like they're trying to require that additional entropy be available, always. (and if you don't have a completely hacked up kernel sysctl is still there..) - maybe we might get something better before it (sysctl) goes away for real instead of just in c-library-du-jour.
You're correct :-) - it does periodically stir in new entropy.
I'm fine with stirring in new entropy after chrooting - I just don't want to see sketchy entropy being used, especially for the initial entropy source. If you could make LibreSSL open (and keep open) /dev/urandom before you chroot, LibreSSL could read additional entropy from the already open file descriptor, even after chrooting.
In any case, note that the chroot issue is a bit of a sideshow compared to the much more serious fork issue.
Not sure how a library is going to keep a caller from closing a descriptor - I've certainly seen people attempt to close them all in code before a fork, but that's probably pathological. However that doesn't work across a re-exec, which would also be good practice in many situations (ASLR) - so having to keep a descriptor open to do this would actually discourage secure programming practices because the library would screw you then. What's here will work in that case from the look of it. (assuming sysctl is there, or the voodoo isn't really that bad, I can't tell myself yet... still looking)
It's reasonable to require that an exec in a chroot have a minimal /dev. If you execute a program in a broken environment, it breaks. That shouldn't be surprising.
There are many potential cases where LibreSSL won't be initialized until after a chroot, by a program with no special rights running inside the chroot, that is entirely unable to open /dev/urandom or create a device node, so this is not a solution.
If that's the case then the fix will not be as simple as I envisioned it. Still, the point stands that LibreSSL should allow you to initialize the PRNG once, before you chroot, so that you can use the PRNG safely once inside the chroot. This could be accomplished by keeping a file descriptor to /dev/urandom open.