(This may seem a little off-topic for the ITP but please bear with me...) On 16/07/14 21:13, Guillem Jover wrote: > kFreeBSD does have a supported sysctl for this: CTL_KERN KERN_ARND. > (As does NetBSD which has two, KERN_URND and KERN_ARND.)
Actually yes, we would certainly want to use that. But is there any conceivable way it could fail? (sysctl calls can return an error code). What could we do then? We'd need to figure this out if we want the prospective libressl package to build on GNU/kFreeBSD on Hurd. Currently it won't build, because it needs either a kernel-specific getentropy implementation, or arc4random. libbsd's arc4random.c, I'm guessing was based on older OpenSSH Portable sources. If reading /dev/urandom fails, it uses only gettimeofday, getpid, and uninitialised bytes from the stack (as a seed to the PRNG). LibreSSL Portable on Linux has the new, scary fallback mechanism instead, more comprehensive, but I honestly don't like that approach. It's too difficult to estimate how much entropy it could really gather, or potential failure cases. And we wouldn't even know when the fallback was being used. Native OpenBSD would actually raise SIGKILL if their sysctl fails. (Their cvsweb is down - quoting inline from arc4random.c instead) : > _rs_stir(void) > [...] > if (getentropy(rnd, sizeof rnd) == -1) > raise(SIGKILL); libevent's arc4stir is different again; it's defined to return an int, with -1 indicating a failure of all attempts to seed: * from /dev/urandom * from /proc/sys/kernel/random/uuid * using a kernel-specific sysctl These arc4random implementations also differ in which stream cipher they use also (RC4 originally, ChaCha20 in newer OpenBSD code). As a result of all this mess, I think we should be looking to converge on a single arc4random implementation, in a place such as libbsd, but make sure it is up to the task first. If arc4random is available and LDFLAGS include -lbsd, LibreSSL Portable will actually use it instead of the bundled implementation. I'm guessing OpenSSH Portable would do this too (I can see it being tested for by ./configure in the buildd log). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
