netdev - Re: [PATCH] SUNRPC: Add a check for gss_release

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-next>] [day] [month] [year] [list]

Message-ID: <YICB3wiptvvtTeA5@mit.edu>
Date:   Wed, 21 Apr 2021 15:49:51 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Weikeng Chen <w.k@...keley.edu>
Cc:     anna.schumaker@...app.com, bfields@...ldses.org,
        chuck.lever@...cle.com, davem@...emloft.net, dwysocha@...hat.com,
        gregkh@...uxfoundation.org, kuba@...nel.org, leon@...nel.org,
        linux-kernel@...r.kernel.org, linux-nfs@...r.kernel.org,
        netdev@...r.kernel.org, pakki001@....edu,
        trond.myklebust@...merspace.com
Subject: Re: [PATCH] SUNRPC: Add a check for gss_release_msg

On Wed, Apr 21, 2021 at 11:35:00AM -0700, Weikeng Chen wrote:
> 
> [1] I think the UMN IRB makes an incorrect assertion that the
> research is not human research, and that starts the entire problem
> and probably continues to be.

I think what we need to somehow establish is some norms about how
academic researchers engage with Open Source communities in general,
and the Linux Kernel community in particular.

To be fair, I don't know if Aditya Pakki was deliberately trying to
get nonsense patches in just to demonstrate that there is less review
for trivial patches, or whether he was creating a completely
incompetent, non-state-of-the-art static code analyzer, and was too
incompetent to hand check the patch to realize the results were
nonsense.

The big problem here is the lack of disclosure that the patch was
computer generated, using a new tool that might not be giving accurate
results, and that instead of diclosing this fact, submitting it as a
patch to be reviewed.  Again, I don't know whether or not this was
submitted in bad faith --- but the point is, Aditya belongs to
research group which has previously submitted patches in bad faith,
without disclosure, and his supervising professor and UMN's IRB
doesn't see any problem with it.  So it's a bit rich when Aditya seems
to be whining that we're not giving him the benefit of the doubt and
not assuming that his patches might have been submitted in good faith
--- when the only *responsible* thing to do is to assume that it is
sent in bad faith, given the past behaviour of his research group, and
the apparently lack of any kind of institutional controls at UMN
regarding this sort of thing.

Of course, UMN researchers could just start using fake e-mail
addresses, or start using personal gmail or yahoo or hotmail
addresses.  (Hopefully at that point the ethics review boards at UMN
will be clueful enough to realize that maybe, just maybe, UMN
researchers have stepped over a line.)

However, your larger point is a fair one.  We do need to do a better
job of reviewing patches, even "trivial" ones, and if that means that
we might need to be a bit more skeptical dealing with newbies who are
trying to get started, that's a price we will need to pay.  Speaking
for myself, I've always tried to be highly skeptical about patches and
give them a thorough review.  And I don't need to assume malice from
nation-state intelligence agencies; we're all human, and we all make
mistakes.

Cheers,

					- Ted