Live data from Hacker News

“They introduce kernel bugs on purpose”

lore.kernel.org

471–480 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#471
post #447

I think Greg KH would have been wise to add a time limit on this ban. Make it a 10-year block, for example, rather than one with no specific end-date. 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…

Presumably they could just talk to the maintainers at that time and have a reasonable discussion.

Re: “They introduce kernel bugs on purpose”

#472
When James O' Keefe tries to run a fake witness scam on the Washington Post, and the newspaper successfully detects it, the community responds with "Well played!"

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.

Re: “They introduce kernel bugs on purpose”

#473
post #342

> I will not be sending any more patches due to the attitude that is not only unwelcome but also intimidating to newbies and non experts. Maybe not being nice is part of the immune system of open source.

Being rude isn't going to discourage malicious actors, who are motivated by fame or wealth.

If you ran a bank and had a bunch of rude bank tellers, you are only going to dissuade customers, not bank robbers.

Re: “They introduce kernel bugs on purpose”

#475
post #342

> I will not be sending any more patches due to the attitude that is not only unwelcome but also intimidating to newbies and non experts. Maybe not being nice is part of the immune system of open source.

"We're banning you for deliberately submitting buggy patches as an experiment."

"Well if you're gonna be a jerk about it, I won't be sending any more patches."

Re: “They introduce kernel bugs on purpose”

#476
post #447

I think Greg KH would have been wise to add a time limit on this ban. Make it a 10-year block, for example, rather than one with no specific end-date. 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…

It isn't hard to get a gmail type address and submit from there.

Re: “They introduce kernel bugs on purpose”

#477

This seems like a pretty scummy way to do "research". I mean I understand that people in academia are becoming increasingly disconnected from the real world, but wow this is low. It's not that they're doing this, I'm sure they're not the first to think of this (for research or malicious reasons), but having the gall to brag about it is a new low.

Agree, and it seems like at least this patch, despite the researcher’s protestations, actually landed sufficiently that it could have caused harm? https://lore.kernel.org/patchwork/patch/1062098/

Re: “They introduce kernel bugs on purpose”

#478
Though I disagree with the research in general, if you did want to research "hypocrite commits" in an actual OSS setting, there isn't really any other way to do it other than actually introducing bugs per their proposal.

That being said, I think it would've made more sense for them to have created some dummy complex project for a class and have say 80% of the class introduce "good code", 10% of the class review all code and 10% of the class introduce these "hypocrite" commits. That way you could do similar research without having to potentially break legit code in use.

I say this since the crux of what they're trying to discover is:

1. In OSS anyone can commit.

2. Though people are incentivized to reject bad code, complexities of modern projects make 100% rejection of bad code unlikely, if not impossible.

3. Malicious actors can take advantage of (1) and (2) to introduce code that does both good and bad things such that an objective of theirs is met (presumably putting in a back-door).

Re: “They introduce kernel bugs on purpose”

#479
Not wanting to play the devil's advocate here but though scummy, they still successfully introduced vulnerabilities to the kernel. Suppose the paper hadn't been released or an adversary had done it. How long they'll be lingering around if they're ever removed? The paper makes a case that FOSS projects shouldn't merely trust authority for security (neither the ones submitting or the ones reviewing) but utilize tools to find potential vulnerabilities for every commit.
Post reply on HN