On Tue, Apr 26, 2016 at 3:11 AM, Theodore Ts'o <tytso@xxxxxxx> wrote: > On Mon, Apr 25, 2016 at 10:23:51AM +0200, Nikos Mavrogiannopoulos wrote: >> That's far from a solution and I wouldn't recommend to anyone doing >> that. We cannot expect each and every program to do glibc's job. The >> purpose of a system call like getrandom is to simplify the complex use >> of /dev/urandom and eliminate it, not to make code handling randomness >> in applications even worse. > Yes, but if glibc is falling down on the job and refusing to export > the system call (I think for political reasons; it's a Linux-only > interface, so Hurd wouldn't have it), I believe their main concern is that they want to protect applications which do not check error codes of system calls, when running on a kernel which does not provide getrandom(). That way, they have an almost impossible task to simulate getrandom() on kernel which do not support it. One may agree with their concerns, but the end result is that we have not available that system call at all, several years after it is there. Anyway it seems that there is some activity now, so hopefully we may have it sometime soon: https://sourceware.org/ml/libc-help/2016-04/msg00008.html regards, Nikos -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
