[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJU7zaKTjb9QhYP6eVyri0b9Ow_GRpqT5HgOVpNMhaEDrVA4gA@mail.gmail.com>
Date: Tue, 3 May 2016 15:57:15 +0200
From: Nikos Mavrogiannopoulos <nmav@...tls.org>
To: "Theodore Ts'o" <tytso@....edu>,
Stephan Mueller <smueller@...onox.de>,
Herbert Xu <herbert@...dor.apana.org.au>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Sandy Harris <sandyinchina@...il.com>
Subject: Re: [RFC][PATCH 0/6] /dev/random - a new approach
On Tue, Apr 26, 2016 at 3:11 AM, Theodore Ts'o <tytso@....edu> 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
Powered by blists - more mailing lists