[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5330121.x9kUHU8cTX@merkaba>
Date: Tue, 17 Sep 2019 22:36:45 +0200
From: Martin Steigerwald <martin@...htvoll.de>
To: Willy Tarreau <w@....eu>
Cc: Lennart Poettering <mzxreary@...inter.de>,
"Theodore Y. Ts'o" <tytso@....edu>,
Matthew Garrett <mjg59@...f.ucam.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Ahmed S. Darwish" <darwish.07@...il.com>,
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>,
"Alexander E. Patrakov" <patrakov@...il.com>,
zhangjs <zachary@...shancloud.com>, linux-ext4@...r.kernel.org,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: Linux 5.3-rc8
Willy Tarreau - 17.09.19, 18:21:37 CEST:
> On Tue, Sep 17, 2019 at 05:57:43PM +0200, Lennart Poettering wrote:
> > Note that calling getrandom(0) "too early" is not something people
> > do
> > on purpose. It happens by accident, i.e. because we live in a world
> > where SSH or HTTPS or so is run in the initrd already, and in a
> > world
> > where booting sometimes can be very very fast.
>
> It's not an accident, it's a lack of understanding of the impacts
> from the people who package the systems. Generating an SSH key from
> an initramfs without thinking where the randomness used for this could
> come from is not accidental, it's a lack of experience that will be
> fixed once they start to collect such reports. And those who
> absolutely need their SSH daemon or HTTPS server for a recovery image
> in initramfs can very well feed fake entropy by dumping whatever they
> want into /dev/random to make it possible to build temporary keys for
> use within this single session. At least all supposedly incorrect use
> will be made *on purpose* and will still be possible to match what
> users need.
Well I wondered before whether SSH key generation for cloud init or
other automatically individualized systems could happen in the
background. Replacing a key that would be there before it would be
replaced. So SSH would be available *before* the key is regenerated. But
then there are those big fast man in the middle warnings… and I have no
clear idea to handle this in a way that would both be secure and not
scare users off too much.
Well probably systems at some point better have good entropy very
quickly… and that is it. (And then quantum computers may crack those
good keys anyway in the future.)
--
Martin
Powered by blists - more mailing lists