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: <YIEO3+jdF6FgcWz7@zeniv-ca.linux.org.uk>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ