linux-ext4 - Re: Linux 5.3-rc8

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <16898130.scaMKaIPcm@merkaba>
Date:   Tue, 17 Sep 2019 10:44:40 +0200
From:   Martin Steigerwald <martin@...htvoll.de>
To:     Willy Tarreau <w@....eu>
Cc:     Matthew Garrett <mjg59@...f.ucam.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "Ahmed S. Darwish" <darwish.07@...il.com>,
        "Theodore Y. Ts'o" <tytso@....edu>,
        Vito Caputo <vcaputo@...garu.com>,
        Lennart Poettering <mzxreary@...inter.de>,
        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, 10:35:16 CEST:
> On Tue, Sep 17, 2019 at 09:33:40AM +0200, Martin Steigerwald wrote:
> > However this again would be burdening users with an issue they
> > should
> > not have to care about. Unless userspace developers care enough and
> > manage to take time to fix the issue before updated kernels come to
> > their systems. Cause again it would be users systems that would not
> > be working. Just cause kernel and userspace developers did not
> > agree and chose to fight with each other instead of talking *with*
> > each other.
> It has nothing to do with fighting at all, it has to do with offering
> what applications *need* without breaking existing assumptions that
> make most applications work. And more importantly it involves not
[…]

Well I got the impression or interpretation that it would be about 
fighting… if it is not, all the better!

> > At least with killing gdm Systemd may restart it if configured to do
> > so. But if it doesn't, the user is again stuck with a non working
> > system until restarting gdm themselves.
> > 
> > It may still make sense to make the API harder to use,
> 
> No. What is hard to use is often misused. It must be harder to misuse
> it, which means it should be easier to correctly use it. The choice of
> flag names and the emission of warnings definitely helps during the
> development stage.

Sorry, this was a typo of mine. I actually meant harder to abuse. 
Anything else would not make sense in the context of what I have 
written.

Make it easier to use properly and harder to abuse.

> > but it does not
> > replace talking with userspace developers and it would need some
> > time to allow for adapting userspace applications and services.
> 
> Which is how adding new flags can definitely help even if adoption
> takes time. By the way in this discussion I am a userspace developer
> and have been hit several times by libraries switching to getrandom()
> that silently failed to respond in field. As a userspace developer, I
> really want to see a solution to this problem. And I'm fine if the
> kernel decides to kill haproxy for using getrandom() with the old
> settings, at least users will notice, will complain to me and will
> update.

Good to see that you are also engaging as a userspace developer in the 
discussion.

Thanks,
-- 
Martin