linux-kernel - Re: [PATCH 000/190] Revertion of all of the umn.edu commits

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]

Date:   Thu, 22 Apr 2021 05:51:27 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Aditya Pakki <pakki001@....edu>, Kangjie Lu <kjlu@....edu>,
        Qiushi Wu <wu000273@....edu>, x86@...nel.org,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Arnd Bergmann <arnd@...db.de>, David Airlie <airlied@...ux.ie>,
        Michael Turquette <mturquette@...libre.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Jean Delvare <jdelvare@...e.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Jiri Kosina <jikos@...nel.org>, Will Deacon <will@...nel.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Johan Hovold <johan@...nel.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Johannes Berg <johannes@...solutions.net>,
        Takashi Iwai <tiwai@...e.com>
Subject: Re: [PATCH 000/190] Revertion of all of the umn.edu commits

On Wed, Apr 21, 2021 at 02:57:55PM +0200, Greg Kroah-Hartman wrote:

> I'll take this through my tree, so no need for any maintainer to worry
> about this, but they should be aware that future submissions from anyone
> with a umn.edu address should be by default-rejected unless otherwise
> determined to actually be a valid fix (i.e. they provide proof and you
> can verify it, but really, why waste your time doing that extra work?)

Frankly, the last bit is nonsense.  If nothing else, consider the situation
when somebody from UMN (which is a lot bigger than the group in question,
but hell with it - somebody really from that group) posts an analysis of
a real bug, along with a correct fix.  With valid proof of correctness.
What should we do?  Leave the bug in place?  Unattractive, to put it
mildly.  Write a fix and try to make it different from theirs?  Not always
feasible.  Write a fix without looking at theirs and commit it?  And if it
happens to coincide with theirs, then what?

FWIW, I do believe their claims that they tried to avoid introducing bugs
and creating problems in general.  So did RT[F]M, for that matter.
However, the very nature of their "experiment"[1] required deflecting
review.  With obvious effects...

[1] I won't go into its value, relevance of threat model, etc. at the
moment - proper comments on that paper will take more time than I'm likely
to have during the next couple of weeks.