“They introduce kernel bugs on purpose” • Hacker News Board

Re: “They introduce kernel bugs on purpose”

#221

Post by duncaen » Wed, Apr 21, 2021, 12:53 PM UTC

bluGill wrote: post #213

rzwitserloot wrote: post #181

The professor gets exactly what they want here, no? "We experimented on the linux kernel team to see what would happen. Our non-double-blind test of 1 FOSS maintenance group has produced the following result: We get banned and our entire university gets dragged through the muck 100% of the time". That'll be a fun paper to write, no doubt. Additional context: * One of the committers of these faulty patches, Aditya Pak…

If the IRB is any good the professor doesn't get that. Universities are publish or perish, and the IRB should force the withdrawal of all papers they submitted. This is might be enough to fire the professor with cause - including remove any tenure protection they might have - which means they get a bad reference. I hope we hear from the IRB in about a year stating exactly what happened. Real investigations of bad con…

See page 9 of the already published paper:

https://raw.githubusercontent.com/QiushiWu/qiushiwu.github.i...

> We send the emails to the Linux communityand seek their feedback. The experiment is not to blame any maintainers but to reveal issues in the process. The IRB of University of Minnesota reviewed the procedures of the experiment and determined that this is not human research. We obtained a formal IRB-exempt letter. The experiment will not collect any personal data, individual behaviors, or personal opinions. It is limited to studying the patching process OSS communities follow, instead of individuals.

Re: “They introduce kernel bugs on purpose”

#222

Post by ret2plt » Wed, Apr 21, 2021, 12:53 PM UTC

throwawaybbq1 wrote: post #65

jedimastert wrote: post #37

Out of curiosity, what would be an actually good way to poke at the pipeline like this? Just ask if they'd OK a patch w/o actually submitting it? A survey?

This is a good question. You would recruit actual maintainers, [edit: or whoever is your intended subject pool] (who would provide consent, perhaps be compensated for their time). You could then give them a series of patches to approve (some being bug free and others having vulnerabilities). [edit: specifying the population of a study is pretty important. Getting random students from the University to approve your se…

This wouldn't really be representative. If people know they are being tested, they will be much more careful and cautious than when they are doing "business as usual".

Re: “They introduce kernel bugs on purpose”

#223

Post by LanceH » Wed, Apr 21, 2021, 12:53 PM UTC

Committing a non-volunteer of your experiment to work, and attempting to destroy their product of their work surely isn't ethical research.

Re: “They introduce kernel bugs on purpose”

#224

Post by ficiek » Wed, Apr 21, 2021, 12:55 PM UTC

Is introducing bugs into computer systems on purpose like this in some way illegal in the USA? I understand that Linux is run by a ton of government agencies as well, would they take interest in this?

Re: “They introduce kernel bugs on purpose”

#225

Post by cblconfederate » Wed, Apr 21, 2021, 12:55 PM UTC

goodpoint wrote: post #146

cblconfederate wrote: post #69

I guess someone had to do this unethical experiment, but otoh, what is the value here? There's a high chance someone would later find these "intentional bugs" , it's how open source works anyway. They just proved that OSS is not military-grade , but nobody thought so anyway

> They just proved that OSS is not military-grade , but nobody thought so anyway ...and yet FOSS and especially Linux is very widely used in military devices including weapons. Because it's known to be less insecure than most alternatives.

I assume they don't use the bleeding edge though

Re: “They introduce kernel bugs on purpose”

#226

Post by kop316 » Wed, Apr 21, 2021, 12:56 PM UTC

rzwitserloot wrote: post #181

The professor gets exactly what they want here, no? "We experimented on the linux kernel team to see what would happen. Our non-double-blind test of 1 FOSS maintenance group has produced the following result: We get banned and our entire university gets dragged through the muck 100% of the time". That'll be a fun paper to write, no doubt. Additional context: * One of the committers of these faulty patches, Aditya Pak…

Hearing how you phrased it reminds me of a study that showed how parachutes do not in fact save lives (the study was more to show the consequences of extrapolating data, so the result should not be taken seriously):

https://www.bmj.com/content/363/bmj.k5094

Re: “They introduce kernel bugs on purpose”

#227

Post by bluGill » Wed, Apr 21, 2021, 12:58 PM UTC

duxup wrote: post #171

ENOTTY wrote: post #22

Later down thread from Greg K-H: > Because of this, I will now have to ban all future contributions from your University. Understandable from gkh, but I feel sorry for any unrelated research happening at University of Minnesota. EDIT: Searching through the source code[1] reveals contributions to the kernel from umn.edu emails in the form of an AppleTalk driver and support for the kernel on PowerPC architectures. In t…

Seems like a bit of a strong response. Universities are large places with lots of professors and people with different ideas, opinions, views, and they don't work in concert, quite the opposite. They're not some corporation with some unified goal or incentives. I like that. That's what makes universities interesting to me. I don't like the standard here of of penalizing or lumping everyone there together, regardless…

One way to get everyone in a university on the same page is to punish them all for the bad actions of a few. It appears like this won't work here because nobody else is contributing and so they won't notice.

Re: “They introduce kernel bugs on purpose”

#228

Post by [deleted] » Wed, Apr 21, 2021, 12:59 PM UTC

[deleted]

Re: “They introduce kernel bugs on purpose”

#229

Post by rzwitserloot » Wed, Apr 21, 2021, 1:01 PM UTC

bluGill wrote: post #213

rzwitserloot wrote: post #181

The professor gets exactly what they want here, no? "We experimented on the linux kernel team to see what would happen. Our non-double-blind test of 1 FOSS maintenance group has produced the following result: We get banned and our entire university gets dragged through the muck 100% of the time". That'll be a fun paper to write, no doubt. Additional context: * One of the committers of these faulty patches, Aditya Pak…

If the IRB is any good the professor doesn't get that. Universities are publish or perish, and the IRB should force the withdrawal of all papers they submitted. This is might be enough to fire the professor with cause - including remove any tenure protection they might have - which means they get a bad reference. I hope we hear from the IRB in about a year stating exactly what happened. Real investigations of bad con…

> I hope we hear from the IRB in about a year stating exactly what happened. Real investigations of bad conduct should take time to complete correctly and I want them to do their job correctly so I'll give them that time

That'd be great, yup. And the linux kernel team should then strongly consider undoing the blanket ban, but not until this investigation occurs.

Interestingly, if all that happens, that _would_ be an intriguing data point in research on how FOSS teams deal with malicious intent, heh.

Re: “They introduce kernel bugs on purpose”

#230

Post by UncleMeat » Wed, Apr 21, 2021, 1:01 PM UTC

scoutt wrote: post #197

ansible wrote: post #164

I still don't get the point of this "research". You're just testing the review ability of particular Linux kernel maintainers at a particular point in time. How does that generalize to the extent needed for it to be valid research on open source software development in general? You would need to run this "experiment" hundreds or thousands of times across most major open source projects.

>the point of this "research". I think it's mostly "finger pointing": you need one exception to break a rule. If the rule is "open source is more secure than closed source because community/auditing/etc.", now with a paper demonstrating that this rule is not always true you can write a nice Medium article for your closed-source product, quoting said paper, claiming that your closed-source product is more secure than…

I don't think this is correct. The authors have contributed a large number of legitimate bugfixes to the kernel. I think they really did believe that process changes can make the kernel safer and that by doing this research they can encourage that change and make the community better.

They were grossly wrong, of course. The work is extremely unethical. But I don't believe that their other actions are consistent with a "we hate OSS and want to prove it is bad" ethos.