Date:   Mon, 30 Nov 2020 16:12:32 +0100
From:   Torsten Duwe <duwe@....de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "Theodore Y. Ts'o" <tytso@....edu>,
        Stephan Müller <smueller@...onox.de>,
        Willy Tarreau <w@....eu>, linux-crypto@...r.kernel.org,
        Nicolai Stange <nstange@...e.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        "Alexander E. Patrakov" <patrakov@...il.com>,
        "Ahmed S. Darwish" <darwish.07@...il.com>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Vito Caputo <vcaputo@...garu.com>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
        William Jon McCann <mccann@....edu>,
        zhangjs <zachary@...shancloud.com>,
        Andy Lutomirski <luto@...nel.org>,
        Florian Weimer <fweimer@...hat.com>,
        Lennart Poettering <mzxreary@...inter.de>,
        Peter Matthias <matthias.peter@....bund.de>,
        Marcelo Henrique Cerri <marcelo.cerri@...onical.com>,
        Neil Horman <nhorman@...hat.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Julia Lawall <julia.lawall@...ia.fr>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        And y Lavr <andy.lavr@...il.com>,
        Eric Biggers <ebiggers@...nel.org>, ardb@...nel.org,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Petr Tesarik <ptesarik@...e.cz>, simo@...hat.com
Subject: drivers/char/random.c needs a (new) maintainer

Hi Linus!

AFAIK it's legit to bother you directly with issues like this one?

I see certifications as the mere messengers here which tell us that
our /dev/random is technologically outdated. Input entropy amounts are
guesstimated in advance, obviously much too conservatively, compiled in
and never checked thereafter; the whitening is done using some home-
grown hash function derivative and other non-cryptographic, non-standard
operations.

All of this does not affect the Linux kernel directly, it will compile
happily, and will run smoothly with all given crypto apps. Only new
crypto keys are generated slower than necessary or, much worse, might
contain less entropy than required because something broke down
unnoticed.  In that case, problems would arise only much later, but in
the real world and with much graver impact. I would rather like to see
the Linux /dev/random being reliable, whether certified or not. If it
provided that reliable entropy fast that would be even cooler. If it
was at least possible to get approval from a standardization body
(without forcing this onto all users, of course) that would be optimal.

Meanwhile there's quite a maintenance backlog; minor fixes are
pending, medium-sized cleanups are ignored and major patch sets to add
the missing features are not even discussed. (I'm deliberately not
including links here to avoid excessive finger pointing.)

I'd like to believe that Ted is too busy working on ext4, but,
especially on explicit request, a "hold on, I'm busy, will get at it
later" or "right, someone wants to take over?" would be appropriate
IMHO. It is also not helpful to object to or ignore all changes which
might benefit certifications just for that sole reason and because of
personal aversion. No reply at all yields exactly the same result as
having no maintainer at all, hence the subject.

Could you please try to get a definite answer from him? I know there
is at least one person (probably more) with enough enthusiasm and
expertise who would happily take over, should that turn out to be a
problem.

Thanks,

	Torsten

Powered by blists - more mailing lists