On 2016-05-03 09:57, Nikos Mavrogiannopoulos wrote:
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.
If it had an existing call, then I could reasonably understand this.
They have no existing wrapper for it, so this really is just BS. If an
application isn't checking error codes, then either:
1. They are intentionally ignoring error codes.
2. It's a bug in the application that needs to be fixed.
The fact that they feel they need to support poorly coded applications
in _new_ system call wrappers is itself somewhat disturbing. There are
no existing applications using this function in glibc because it doesn't
exist in glibc, which means they can't claim legacy support and
therefore they want to actively enable people to write stupid programs.
--
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
