[0] https://cse.umn.edu/cs/statement-cse-linux-kernel-research-a...
https://github.com/QiushiWu/QiushiWu.github.io/blob/main/pap...
See section VI-A (page 8).
>... learned today about the details of research being conducted by one of its faculty members and graduate students into the security of the Linux Kernel
And this sounds like mainly a lot of damage control is going to happen.
>We will report our findings back to the community as soon as practical.
Social shame and reputation damage may be useful defense mechanisms in general, but in a hacker culture where the right to make up arbitrarily many secret identities is a moral imperative, people who burn their identities can just get new ones. Banning or shaming is not going to work against someone with actual malicious intent.
From what I understand, this answer seems to be a "yes".
Of course, it is understandable that GKH is frustrated, and if his community do not like someone pointing out this issue, it is OK too.
However, one researcher does not represent the whole university, so it seems immature to vent this to other unrelated people just because you can.
Besides, how to test the idea without doing what they did? Can you show us a way?
What happens if any of that patches ends up in a kernel release?
It's like setting random houses on fire just to test the responsiveness of local firefighters.
This news makes me wish to implement my own block on the same contributors to any open source I'm involved with. At the end of the day, their ethics is their ethics. Those ethics are not Linux specific, it was just the high profile target in this instance. I would totally subscribe to or link to a group sourced file similar to a README.md or CONTRIBUTORS.md (CODERS_NON_GRATA.md?) that pulled such things.
There is also a more nuclear option which I'm specifically not advocating for quite yet here but I will note none the less;
We're starting to see in discourse regarding companies co-opting open source projects for their own profit (cough Amazon) and how license agreements limit them more than regular contributors. That has come about, at the core of it, also because of a demonstrated trend of bad faith but also combined with a larger surface area contact with society. I could foresee a potential future trend where individuals who also act in bad faith are excluded from use of open source projects through their licenses. Imagine if the license for some core infrastructure tech like a networking library or the Linux kernel banned "Joe Blackhat" from using python for professional use. Now he still could, but in reputable companies, particularly larger ones with a legal department that person would be more of a liability than they are worth. There can be potentially huge professional consequences of a type that do not currently exist really in the industry.
Researcher sends bogus patches to bazaar-style project, gets them reviewed and approved, uses that to point how ridiculous the review process of the project is => DON'T DO THAT! BAD RESEARCHER, BAD!
Thought to be fair, it is also the case that only the most irrelevant journals are likely to accept the most bogus papers. But in both cases I see no reason not to point it out.
The two situations are much more closer than what you think. The only difference I see is in the level of bogusness.
Imagine what happens 25 years from now as some ground-breaking security research is being done at Minnesota, and they all groan: "Right, shoot, back in 2021 some dumb prof got us banned forever from submitting patches".
Is there a mechanism for University of Minnesota to appeal, someday? Even murders have parole hearings, eventually.
This is obviously the complete opposite of how you should be communicating with someone in most situations let alone when you want something from them.
I have sure been there though so if anything, take this as a book recommendation for 'How to Win Friends & Influence People'.
> I've never read it, but
If you've never read it, maybe just leave it at that.
> manipulating people
You mean "influencing people", like it says right in the title?
It's a book that has helped millions, which is why it continues to be widely recommended.
It's not for everyone. The advice seems obvious to some, which of course is why it can be so valuable for others.
Just have a go at it, it costs less than a euro as an e-book and it read so easily that you’ll be done in no time.
Edit: turns out it was just that there were two different threads on the frontpage about this story and a moderator downweighted the earlier one. That's standard moderation. Usually we merge the threads (and I've since done so) but I'm the only mod who currently does that and I wasn't online yet.
It's clear to me now that this case was a moderation mistake. We make them sometimes (alas), but that's also been true for many years. Moderation is guesswork. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Other than that, they got caught red-handed accepting shit patch and complain about ethical issues when the fault is entirely on their side for not doing their job properly.
This whole thing points to a single question: how many times did they accept patch from black hat individuals who did not disclose their intention ?
This question the Linux development security model and highlight it being insecure to such social engineering attacks and they still manage to play victims. That's pitiful... Own it, say you fucked up accepting the patch, don't blame other for your own incompetence.
When a university submits intentionally buggy patches to the Linux Kernel, and the maintainers successfully detect it, the community responds with "That was an incredibly scummy thing to do."
I sense a teachable moment, here.
