On Wed, 21 Apr 2021, Roland Dreier wrote:

> On Wed, Apr 21, 2021 at 12:22 PM Steven Rostedt <rostedt@goodmis.org> wrote:
> > I have no problem with taking a trivial patch if they are really fixing a
> > bug. I think what needs to be done here is look at the patches that got in
> > that were buggy, and see why they got in.
> >
> > Perhaps the answer is to scrutinize trivial patches more. To me, the only
> > "trivial" patch is a comment fix, or update to documentation. And even
> > then, I spend time reviewing it.
> >
> > If you don't have time to review a patch, then by all means, don't accept
> > it. Perhaps the answer is simply have a higher bar on what you do accept.
> >
> > There are a few people that I will accept patches from with out review. But
> > anyone else, I scrutinize the code before taking it in.
>
> I agree with this.  And indeed to me perhaps what needs to be
> calibrated is our definition of a trivial patch.
>
> If someone sends a patch that changes "speling" to "spelling" in a
> comment, then I think that's fine to apply without much scrutiny.  If
> someone sends a patch that changes reference counting on an error
> path, then that absolutely needs to be looked at to ensure
> correctness.  There are enough people sending wrong patches without
> even thinking about malicious actors.
>
> I also think there does need to be a strong sanction against this UMN
> research group, since we need to make sure there are strong incentives
> against wasting everyone's time with stunts like this.  Hopefully on
> the academic side it can be made clear that this is not ethical
> research - for example, why did IEEE think this was an acceptable
> paper?

The author's web page (https://www-users.cs.umn.edu/~kjlu/) says:

On the Feasibility of Stealthily Introducing Vulnerabilities in
Open-Source Software via Hypocrite Commits
Qiushi Wu, and Kangjie Lu.
To appear in Proceedings of the 42nd IEEE Symposium on Security and
Privacy (Oakland'21). Virtual conference, May 2021.
★ Note: The experiment did not introduce any bug or bug-introducing
commit into OSS. It demonstrated weaknesses in the patching process in a
safe way. No user was affected, and IRB exempt was issued. The experiment
actually fixed three real bugs. Please see the clarifications.
https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf

He's on the program committee of the conference for next year...

[I'm just providing information, not implying that I agree with it]

julia