Comment by StefanKarpinski | Hacker News Reader

Comment by StefanKarpinski | Hacker News Reader

Parent Full thread

StefanKarpinski

The thing I’m still missing is a detailed explanation of what the heck was going on with the recent bogus commit that triggered the banning. Supposedly the “hypocrite commit” research was all done in 2020 and is now in the past. So what was going on with this latest bad commit? The student who submitted it claimed it was generated by a static analysis tool, which kernel maintainers have plausibly called bullshit on. Was that student lying? If so, what were they actually doing? If not, it seems absolutely necessary at this point to prove that they were telling the truth by publishing how that commit was produced, including the tool’s source code and how it was invoked. Even if the campaign to intentionally introduce security flaws was over in 2020, the more recent issue is that the same research group submitted an apparently intentionally incorrect patch and then seems to have lied about its provenance and why it was submitted. Until that’s cleared up any kind of apology feels premature and impossible to evaluate. How can anyone decide if an apology is sincere without understanding what was done?

The latest patch adds a null check around a call to gss_release_msg. The commit message says “ The patch adds a check to avoid a potential double free.”

According to other people in the conversation, this is already taken care of by reference counting (https://lore.kernel.org/linux-nfs/20210407153458.GA28924@fie... ) and the patch apparently does nothing. The commit doesn’t reference any specific tool they’re using, or any bug they faced.

Looks innocuous, but I guess past behaviour from this group left enough of a bad taste for Greg KH to be suspicious.

A later message claims (outraged at being accused of submitting intentionally broken code to the kernel, despite having previously done exactly that) that the patch was generated by a static analysis tool. Ok, what tool? How did you run it? The message where he claims this has since been deleted (by who? Edit: probably never sent to the list, see below) but here is a message from Greg KH which quotes it:

https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah...

You can see that Greg KH is skeptical that the patch was generated by a tool. It’s also unclear to me if the patch is actually harmless or not. It would be good to get some definitive clarity on that but the lkml discussion of it seems inconclusive.

I would add that the student’s tone in this message feels really familiar as an open source maintainer: this is the tone of someone doing something they know is bad being called out on it and trying to deflect with outrage. The last time I got that tone, it was someone who had created multiple sock puppet accounts to try to discredit my project and force moderators to reverse or apologize for a (completely justified and mild) moderation action. So I can’t help but feel that something fishy is going on here and the UMN research group still isn’t being honest about it.

My understanding is that the "not found" messages were never archived, rather than deleted. Likely they were not CC'd to the list, and the replies added the list back to CC.

Cf https://lore.kernel.org/linux-nfs/YIUMYYcf%2FVW4a28k@kroah.c...

Apparently, they sent html mails, which the list refuses to deliver.

Thanks for explaining that!

My experience of GKH's work isn't generally very favourable; but my estination of him has been increased by this repair. He's created work for himself, but it needed doing. Credit where it's due.

> Looks innocuous, but I guess past behaviour from this group left enough of a bad taste for Greg KH to be suspicious.

The idea of the kind of research they previously did is to submit patch requests with some kind of trick or hidden agenda first, then do some analysis of the results, and then later on publish a paper explaining what they did.

Now here they are again submitting a weird looking and seemingly poorly conceived patch. Who knows what they're really doing? Perhaps they're working on some kind of new paper, with who know what purpose. Maybe they'd find out in 6 months. Maybe it's a failed line of research similar to the previous ones which they won't actually publish. Or maybe they just have no idea what they're doing. Either way, it seems like a waste of time at best. The mass ban and revert sounds like an appropriate move.

Reply on news.ycombinator.com