From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E701971 for ; Thu, 22 Apr 2021 08:45:34 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 232FF61426; Thu, 22 Apr 2021 08:45:30 +0000 (UTC) Date: Thu, 22 Apr 2021 10:45:27 +0200 From: Christian Brauner To: Mike Rapoport Cc: Geert Uytterhoeven , James Morris , Julia Lawall , Stephen Hemminger , Roland Dreier , Steven Rostedt , James Bottomley , ksummit@lists.linux.dev Subject: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Message-ID: <20210422084527.u4otu3ccanckrjll@wittgenstein> References: <20210421152209.68075314@gandalf.local.home> <20210421132824.13a70f6c@hermes.local> X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Thu, Apr 22, 2021 at 10:51:12AM +0300, Mike Rapoport wrote: > Hi, > > On Thu, Apr 22, 2021 at 09:34:38AM +0200, Geert Uytterhoeven wrote: > > On Wed, Apr 21, 2021 at 11:50 PM James Morris wrote: > > > On Wed, 21 Apr 2021, Julia Lawall wrote: > > > > The apology states that they didn't detect any vulnerabilities. They > > > > found three non exploitable bugs and submitted incorrect patches for them. > > > > When the patches received some positive feedback, they explained that the > > > > patches were incorrect and provided a proper fix. > > > > > > > > So they damaged trust, but not actually the Linux kernel... > > > > > > The issue is that there was no consent and no coordination, so we don't > > > know the scope of the experiment and whether it was still continuing. > > > > > > We are this not able to trust anything the group said about what they'd > > > done or not done, until now [1]. > > > > > > In all probability there is nothing further amiss but we would not have > > > expected them to use fake gmail accounts to submit bugs to the kernel > > > either. > > > > > > It's now on us to audit all of their known contributions, because we don't > > > know the scope of the experiment, which was based on the use of deception, > > > and we can't make any assumptions based on what they have said. > > > > > > We also need the identity of the 'random' gmail accounts they used, > > > although this should be handled by a small trusted group in private, as it > > > will lead to privacy issues for kernel maintainers who responded to them > > > in public. > > > > What do we gain by blindly reverting all[1] umn.edu patches, and > > ignoring future patches from umn.edu? > > I think all of this is moot: other people may be doing the same thing, > > or even "in worse faith". The only thing that helps is making sure > > patches get reviewed[2] before being applied. > > > > [1] Judging from the new review comments, many of the 190 patches > > to be reverted were real fixes. > > [2] Whether we can trust the reviewers is another question, and might > > become the topic of another research project :-( > > Hopefully such research will require too much effort and won't get funding :) > > Now seriously, I agree with Jiri that this research is proving the obvious > that given enough effort somebody can add malicious code to any open source Research like this has existed before. They even link to some of it in their paper. Their "hypocritial commit" concept seems like a classic example of giving a corner-case its own definition (Which is fine of course.). They essentially seem to argue that it's different from Trojan Horse commits that introduce direct vulnerabilities aka the classic (2003?) if (foo & (__WCLONE | __WALL) && current->uid = 0) in that they introduce vulnerabilities as side-effects which yeah. It's good that it triggered a discussion even if the way this is done is (also academically) suboptimal. There's a reason why prior research into Trojan Horse contributions didn't just go out and try to place bugs into existing software on such a large scale. (The fact that even one buggy commit - accident or not - from their group made it into the kernel renders the whole research project ethically questionable.) Does the possibility of introducing bugs on purpose have to have immediate global consequences for our review processes is a question I find particularly hard to answer. Even with all the consolidation effort over the last (2) years subsystems are still managed very differently and the review quality and quantity a patch or patch series will get may be vastly different.