University of Minnesota Linux "Hypocrite Commit" Researchers Publish Open Letter

[oiaohm]

If it was a criminal action, that's subject to the justice system, not the linux foundation. And if you want a quality inspection, the element of surprise is essential.

Are they pressing criminal charges against a select group of individuals responsible, are they launching a lawsuit, or are they resorting to a blanket ban, an action about as stupid as the reason that prompted it in the first place?

This is not known the law. You have a duty of care under law and you have requirement not to waste the courts time. So before you can press criminal charges for a sabotage you are meant to attempt to rectify issue. So banning them is precursor to possible legal action. If the party attempts to work around the ban/dismissal taking them to court then not wasting the courts time to go to criminal charges.

There is a order of operations here.
1) Notification that they were doing wrong things that was sent on the first paper. This is the first step leading to possible sabotage charges.
2) Banning them is is the second step leading to possible sabotage changes.
3) Sabotage charges. including the possibility of being charged in many countries at once.

ddriver there are two possible legal charges here.
1) Negligence this goes back on the maintainers if they have not taken action in the form of banning or otherwise against the part doing Sabotage.
2) Sabotage.

The maintainers to protect themselves against a Negligence charge there hand is forced on the ban.

Except that they did not inject anything. They put something that could not possibly pass inspection on the inspection line. And if this thing got merged and caused damage, it would be the product of reviewer and maintainer incompetence and failure to do their job at a proper level.

No with sabotage charge you are not allowed to say that I was sure that could not possible pass inspection as this says you knew what you were doing was defective yes intentional defective action is sabotage.

The reviewer and maintainer incompetence is a different change called Negligence.

The reality they wanted to find out how Linux kernel maintainers respond to defective patches. They are legally required to ban. Why would they ban the university not the individual because there is no point taking legal action the individual because they will not pay the legally cost.

ddriver its about time you stop ignoring the sabotage law. The sabotage law means you need to be really careful what you submit.

https://www.atlassian.com/git/tutori...tory/git-blame Git has git blame for the very reason of find who added a fault. This is the person who wrote the patch and the reviewers and maintainers who missed it. Most cases it deterred to be human error as in they did not know what they were doing was wrong this is not in fact illegal. The problem with these current cases they knew what they were submit was wrong this makes it intentional action of sabotage and illegal without massive due care.

When they say the could not get proper results by informing maintainers this is a mega red flag. There are many levels of maintainers in the Linux kernel like Linus himself does not take in entry level patches at all. Everything Linus puts into the kernel has to be signed off by another maintainer first even his own patches. There were maintainers that could have been informed that would not have biased the results there were in locations to setup detection barriers. Of course its likely those maintainers would all say no way we will approve this but that is the way the cookie at time crumbles when you want to-do legal research that you cannot do it due to lack of approval.

There are 3 maintainers that need to be informed in fact.

https://www.kernel.org/category/releases.html

Linus Torvalds for mainline protection
Greg Kroah-Hartman & Sasha Levin for LTS releases of Linux kernel protection.

So should Greg Kroah-Hartman on a research project on the Linux kernel git trees done by submitting patches be in the dark about absolutely no he should be informed he is a critical gate keeper. If you are doing this kind of research and those 3 parties are not informed and have not given their approval it is sabotage and lack of due care on your part if you get caught doing it.

It does not take very much work to find who is in-charge of doing releases.

[coder]

if you want a quality inspection, the element of surprise is essential.

There are different ways to achieve that. Even if there weren't, there's no footnote in ethical research guidelines that says you're allowed to use unethical means if you can't find an easy way to do it ethically.

For one thing, if Linus had bought into the experiment, then at least he could prevent the changes from reaching a release candidate. However, that's still not great, since it means the other subjects haven't given informed consent.

If the necessary information can't be gleaned from studying the kernel's bug database, repo, and mailing lists, then a controlled study can be conducted. This could take the form of engaging fellow students around a set of open source projects that the researchers would like to study. The students can be assigned to teams at random, which would let the researchers insert insiders into some of the teams. The study participants need not be informed of precisely what the researchers will be studying. Indeed, a lot of psychology and sociology studies use some form of gentle misdirection, so that the participants won't be guarded with respect to the study's focus.

I don't really see this any more harmful than say, the practice of intelligent agencies ...

So, if spies ocassionally kill people, does that make it okay for anyone to commit murder?

This situation is a victimless transgression, the effort was nowhere near to doing any actual harm.

Since when are use-after-free bugs victimless? And even though those were caught, dealing with those submissions wasted people's time who I'm sure have better things to do! And having to re-review other UMN patches is undoubtedly wasting even more time!

You seem to have a distorted view of what qualifies someone as a victim.

[coder]

Also, quite a lot of "bad faith" mentions here - that doesn't seem correct IMO. Bad faith could be the case only if there was nefarious intent. Did they have a criminal motive to do what they did?

"Bad faith" simply means intention to cause harm.

To test whether something is vulnerable in order to inform the party responsible for addressing that if it was the case - that is not bad faith, it is good faith... if there is even such a thing.

Unauthorized penetration testing is still classified as hacking and subject to the same laws, regardless of the perpetrator's intent. It's only at the time of sentencing where intent is usually taken into account.

That said, I'm not claiming that inserting kernel bugs is governed under the same laws as penetrating a specific computer system, but the analogy is definitely informative. To put it plainly: don't fuck with someone's shit without asking. It's just common sense.

[oiaohm]

Since when are use-after-free bugs victimless?

And even though those were caught, dealing with those submissions wasted people's time who I'm sure have better things to do! And having to re-review other UMN patches is undoubtedly wasting even more time!

You seem to have a very distorted view of what qualifies someone as a victim.

Lot of the errors were not use after free purely but duplicate frees these do have their dangers. Even so with different flaws that can be hidden in the Linux kernel based on timing you can open up a security flaw by making execution in particular points faster or slower.

Its very hard to say a patch is harmless because the Linux kernel is a very complex thing. Some alterations that their patches triggered required had to be removed because it caused a performance regression from the first round. Human error is a factor that the Linux kernel development is constantly fighting against. Heck Microsoft with their own internal developers have the same problem.

It does not matter under law you are not allowed to use people as test subjects without at least some approval from them and you have a duty of care to make sure your research does not cause harm. If you cannot put the systems in place properly to be sure that you will not cause harm in most cases you should not perform the research.

There were 3 parties in the Linux kernel who need to sign off for this kind of research to be done. We know they did not and worst they admit that they were not asking.

I love how they say there were developing a new tool for code quality yet under Linux kernel submit rules if you are using a tool its name should be name: at the start of the subject on the patch there patches are lacking the mark to say done by some tool or as result of some tool finding. So the second time they are still disobeying Linux kernel submit rules.

[leo_sk]

Well, those commits came from Earth, so I guess banning the entire planet from contributing is more or less in the same ballpark with banning an entire university over what a couple of morons did.

I see you are trying to excessively extrapolate to create a weak argument where none exists, but it would be more helpful to your case if you rather explain why the University should not be held responsible.

[ddriver]

. . . This is kind of like my theory that extremely cynical people just like to believe that everyone else is as unscrupulous as they are, in order to make themselves feel better about their own self-dealing

I suggest you put precedence on what people do rather than what they say. I have no urges to see things any better or worse than they are. I am fine with acknowledging reality with its problems, because you cannot solve problems you aren't willing or able to acknowledge, and most problems you cannot really escape.

I do not consider myself unscrupulous, even back in my days of graphics design, I do recall putting quite a lot of attention and care into "single pixel" trivial matters than I've seen medical professionals utilize when dealing with human lives, which IMO is something extremely unethical and worthy of extreme criminal punishment. I honestly do wish when my times comes to receive medical care, it is from someone with my degree of unscrupulousness.

It is 99% about money and 1% about power, we have an entire medical industry that works hand in hand with other industries to make the population sicker and thus more medically profitable, and nobody seems to have an ethical issue with that.

But you have an ethical issue with some students doing a study to see whether quality control will catch bad commits as they should, the world for that is drama queen. And if you believe that human morals or ethics are allowed to take precedence to money and power, you are a naive child at best. I am not saying that they shouldn't, just that they don't outside of the context of public theatrics and comforting wishful thinking.

It may also be worth mentioning that I do not believe this is the product of some fundamental and inevitable human flaw as most cynics do. IMO it is all a product of our environment and totally reversible. It is just that it is not a subject of "make-believe".

[leo_sk]

So are you saying that it is not a viable research field to determine if there are possibilities to establish viable attack vectors by means of code contribution?

Why not prevent .... say vehicle safety inspection tests from doing anything that the vehicle manufacturer hasn't authorized explicitly?

Sure, but it is more akin to a situation like a component manufacturer sends bad components to the vehicle manufacturer, who is unaware of the defects in those components, just to research how easily those components are included in the final vehicle that are sold to customers.
Is it okay for the safety of customers to be compromised?

[jaxa]

Hmm... They do not get it....

(1) What they did is a CRIME.

(2) They face JAIL TIME.

If you want to research how bad code gets into the Kernel (deliberately or otherwise), there's a massive list of existing patches and Git logs for your research. You don't need to submit your own bugs. Penetration testing without authorisation is colloquially called "computer hacking".

CFAA §1030? Good luck with that. I think the prosecutors in Minnesota are busy right now. xD

[coder]

Enough with all this horseshit feel-good virtue signalling.

How is it virtue signalling if no one here knows who I am and if I don't give a damn what they think about me, anyway?

I'm here precisely because it lets me discuss ideas and topics I care about or find interesting, without a whole bunch social baggage!

If it were one of Microsoft's open source projects or even the Windows code that was targeted by the researchers, most of people people in here will singing a goddamned different tune.

I wouldn't, nor do I suspect most others would. I'll grant you that some would, but not most.

[OneTimeShot]

But you have an ethical issue with some students doing a study to see whether quality control will catch bad commits as they should, the world for that is drama queen. And if you believe that human morals or ethics are allowed to take precedence to money and power, you are a naive child at best. I am not saying that they shouldn't, just that they don't outside of the context of public theatrics and comforting wishful thinking.

No one has an ethical issue with students researching QA processes of the Linux Kernel. A few people have issues with the University "Ethics Committee" allowing them to potentially break the law by not following standard penetration testing authorisation procedures.

If Linus replied to the thread and said "don't worry - they discussed this project with me and I thought it was valuable, there was no chance that the patch would get through to the final tree" there would be no (or at least, far less of) a problem.

As is, these students did the computer security equivalent of a doctor performing an operation without the patent's approval. Nothing bad actually happened, but they are still potentially in legal difficulties.