University of Minnesota Researchers Send Apology to Linux Kernel Mailing List (kernel.org) 208
Earlier this week Greg Kroah-Hartman of the Linux kernel development team banned the University of Minnesota from contributing after researchers there submitted what he called "obviously-incorrect patches" believed to be part of a research project into whether buggy code would be accepted.
Today the professor in charge of that project, as well as two of its researchers, sent an email to the Linux kernel mailing list saying they "sincerely apologize for any harm our research group did to the Linux kernel community." Our goal was to identify issues with the patching process and ways to address them, and we are very sorry that the method used in the "hypocrite commits" paper was inappropriate. As many observers have pointed out to us, we made a mistake by not finding a way to consult with the community and obtain permission before running this study; we did that because we knew we could not ask the maintainers of Linux for permission, or they would be on the lookout for the hypocrite patches. While our goal was to improve the security of Linux, we now understand that it was hurtful to the community to make it a subject of our research, and to waste its effort reviewing these patches without its knowledge or permission.
We just want you to know that we would never intentionally hurt the Linux kernel community and never introduce security vulnerabilities. Our work was conducted with the best of intentions and is all about finding and fixing security vulnerabilities... We are a research group whose members devote their careers to improving the Linux kernel. We have been working on finding and patching vulnerabilities in Linux for the past five years...
This current incident has caused a great deal of anger in the Linux community toward us, the research group, and the University of Minnesota. We apologize unconditionally for what we now recognize was a breach of the shared trust in the open source community and seek forgiveness for our missteps. We seek to rebuild the relationship with the Linux Foundation and the Linux community from a place of humility to create a foundation from which, we hope, we can once again contribute to our shared goal of improving the quality and security of Linux software... We are committed to following best practices for collaborative research by consulting with community leaders and members about the nature of our research projects, and ensuring that our work meets not only the requirements of the Institutional Review Board but also the expectations that the community has articulated to us in the wake of this incident.
While this issue has been painful for us as well, and we are genuinely sorry for the extra work that the Linux kernel community has undertaken, we have learned some important lessons about research with the open source community from this incident. We can and will do better, and we believe we have much to contribute in the future, and will work hard to regain your trust.
Their email also says their work did not introduce vulnerabilities into the Linux code. ("The three incorrect patches were discussed and stopped during exchanges in a Linux message board, and never committed to the code.")
And the email also clarifies that their research was only done in August of 2020, and "All the other 190 patches being reverted and re-evaluated were submitted as part of other projects and as a service to the community; they are not related to the 'hypocrite commits' paper. These 190 patches were in response to real bugs in the code and all correct — as far as we can discern — when we submitted them... Our recent patches in April 2021 are not part of the 'hypocrite commits' paper either."
UPDATE (4/25): Late Saturday night the kernel team's Greg Kroah-Hartman rejected the apology, writing that "the Linux Foundation and the Linux Foundation's Technical Advisory Board submitted a letter on Friday to your University outlining the specific actions which need to happen in order for your group, and your University, to be able to work to regain the trust of the Linux kernel community.
"Until those actions are taken, we do not have anything further to discuss about this issue."
Today the professor in charge of that project, as well as two of its researchers, sent an email to the Linux kernel mailing list saying they "sincerely apologize for any harm our research group did to the Linux kernel community." Our goal was to identify issues with the patching process and ways to address them, and we are very sorry that the method used in the "hypocrite commits" paper was inappropriate. As many observers have pointed out to us, we made a mistake by not finding a way to consult with the community and obtain permission before running this study; we did that because we knew we could not ask the maintainers of Linux for permission, or they would be on the lookout for the hypocrite patches. While our goal was to improve the security of Linux, we now understand that it was hurtful to the community to make it a subject of our research, and to waste its effort reviewing these patches without its knowledge or permission.
We just want you to know that we would never intentionally hurt the Linux kernel community and never introduce security vulnerabilities. Our work was conducted with the best of intentions and is all about finding and fixing security vulnerabilities... We are a research group whose members devote their careers to improving the Linux kernel. We have been working on finding and patching vulnerabilities in Linux for the past five years...
This current incident has caused a great deal of anger in the Linux community toward us, the research group, and the University of Minnesota. We apologize unconditionally for what we now recognize was a breach of the shared trust in the open source community and seek forgiveness for our missteps. We seek to rebuild the relationship with the Linux Foundation and the Linux community from a place of humility to create a foundation from which, we hope, we can once again contribute to our shared goal of improving the quality and security of Linux software... We are committed to following best practices for collaborative research by consulting with community leaders and members about the nature of our research projects, and ensuring that our work meets not only the requirements of the Institutional Review Board but also the expectations that the community has articulated to us in the wake of this incident.
While this issue has been painful for us as well, and we are genuinely sorry for the extra work that the Linux kernel community has undertaken, we have learned some important lessons about research with the open source community from this incident. We can and will do better, and we believe we have much to contribute in the future, and will work hard to regain your trust.
Their email also says their work did not introduce vulnerabilities into the Linux code. ("The three incorrect patches were discussed and stopped during exchanges in a Linux message board, and never committed to the code.")
And the email also clarifies that their research was only done in August of 2020, and "All the other 190 patches being reverted and re-evaluated were submitted as part of other projects and as a service to the community; they are not related to the 'hypocrite commits' paper. These 190 patches were in response to real bugs in the code and all correct — as far as we can discern — when we submitted them... Our recent patches in April 2021 are not part of the 'hypocrite commits' paper either."
UPDATE (4/25): Late Saturday night the kernel team's Greg Kroah-Hartman rejected the apology, writing that "the Linux Foundation and the Linux Foundation's Technical Advisory Board submitted a letter on Friday to your University outlining the specific actions which need to happen in order for your group, and your University, to be able to work to regain the trust of the Linux kernel community.
"Until those actions are taken, we do not have anything further to discuss about this issue."
Pointless Apology (Score:5, Insightful)
Re: (Score:2)
Re:Pointless Apology (Score:5, Funny)
Re:Pointless Apology (Score:4, Insightful)
Fuck'em
Re: (Score:2, Interesting)
File the criminal charges to shut them up if they haven't got the hint that nobody can trust the asshole who cried wolf with critical infrastructure. They could've killed people.
Re:Pointless Apology (Score:4, Insightful)
Re:Pointless Apology (Score:4, Insightful)
Re: Pointless Apology (Score:2)
Re:Pointless Apology (Score:5, Informative)
Sure seems like this was a sanctioned task with oversight
From the point of view of the university, it was. But this is in fact the actual problem. Because from the view of the people maintaining the kernel merge process, it absolutely was not sanctioned. If they had discussed this with maintainers ahead of time, then they could have avoided the entire flap, and the entirely justifiable ban on commits.
This experiment showed several flaws in the change control and approval process that a true malicious actor could target to get a bug committed that should be taken seriously
The code was not approved, and therefore demonstrated the security of the change control and approval process.
Re:Pointless Apology (Score:5, Insightful)
They've lied and deceived. How can you trust them? Why should you trust them? What makes you believe this is an honest apology rather than just an attempt to regain submit privileges?
And when they say the "hope to do better", that could be interpreted in many ways, not all favorable to the Linux community.
A genuine apology comes with amends.
Re:Pointless Apology (Score:4, Insightful)
2. Nevertheless, they showed that you can't trust them.
Net result, they apologized, their apology should be accepted, but you still can't trust them.
it's not three coders who were banned (Score:3, Interesting)
Re: (Score:2)
Much easier for code reviewers to ban these three for life
Except their patches closed security issues, and the reversion or rejection of their fixes can potentially lead to weaponization of known bugs regressions will reintroduce.
Banning also does not mean these 3 cannot harm the kernel -- their work is to find security bugs, so they could simply find more, and focus their work on developing exploits for the bugs they find instead of fixes, then keep the exploits secret and sell the details to the highest
Re: (Score:2)
Reject their patches, open issues, create clean slate patches.
Re:Pointless Apology (Score:5, Interesting)
Yeah, it was just an apology, but nothing more. I saw it as "We're sorry, no harm no foul, all good, ok?".
If they wanted to apologize, they should've offered something in return - resources of some kind. I'm sure they could've donated a few thousand dollars to the Linux Foundation or find some other means to help out the community. That would show a real apology for the extra time and effort their work was doing.
And honestly, informed consent is possible - I'm sure they could've talked to say, Linux himself to help oversee the entire process. Linux might not be involved in the day to day coding which means he's no longer overseeing the patches, but at least he'll be in the know and be notified which patches would be the "bad" patches or ones that might need further review later. A maintainer who doesn't deal with the day to day, but still has the power to fix things.
Even getting in touch with Greg would be possible to alert him to the fact - he could easily arrange for someone else to take care of his duties during an agreed-upon time period (since everyone needs a just-in-case-of-bus) and seeing how things work out.
If they really cared, they'd solicit reparations from the community - not just a mea culpa. Money, resources, anything else the kernel developers might want or need. Or even just donations to the EFF, EPIC or other group. These guys benefited because of their paper, at the expense of the kernel development community as a whole. An apology isn't enough.
Re:Pointless Apology (Score:5, Insightful)
We're sorry we got caught.
Sincerely, The University of Minnesota
Re: (Score:2)
Much easier for code reviewers to ban these three for life, than to have to triple check every patch they submit for Underhanded C shenanigans.
They probably won't try that.
But also, according to the paper, they used random Gmail accounts to submit the three "hypocrite commits".
Re: BIAS accusation (Score:3)
Let's not forget the graduate student accusing Greg Kroah-Hartman of "preconceived biases" in the original email response. Because if there's one way to get attention off something you did wrong, is to accuse the opponent of racism.
Re: (Score:3)
Hee hee, let's require them to openly support Stallman and the Free Software Foundation as penance.
Re: (Score:2)
Re: (Score:3)
a foundation of SJWism is a complete lack of forgiveness and no path to redemption. One mistake and your soul is permanently damned.
Ah, so you were the anonymous coward that replied to my other comment.
Re:Pointless Apology (Score:5, Informative)
a foundation of SJWism is a complete lack of forgiveness and no path to redemption. One mistake and your soul is permanently damned.
FWIW, I see at least TWO mistakes.
They HAD to intentionally mislead the IRB at the University, and IRB approved a "no human subjects" study waiver. Because if the IRB members understood that they are talking about performing human subject experiments without subject's knowledge, this would never be approved.
They wanted to improve the Linux patching process, which I believe means they performed a study on humans who reviewed these patches.
Re: (Score:2)
Journalists do this all the time with corporations. They've even had laws a d court cases ruminating through it.
It's ironic many screetching here would be all "yeah yeah get 'em!" the next time such a story comes through slashdot.
Nobody seems to have problems when the same is done to political campaigns to gain info.
Re: (Score:2)
Except journalists don't have a dedicated "department" (dunno, at the college I work for the IRB is one person... but then, we're a junior tech school, not a research institution) that is supposed to review all research proposals to cover legalities, sharing of info with others, and ethical/moral issues like research on living or sentient beings.
Re: (Score:3)
Human society heavily relies on trust, thus once the trust is broken consequences are severe.
People involved in this project do quite important and rather difficult work mostly for free (I am not involved), so why to expect them to accept contributions from someone, who knowingly harmed the project for personal benefits?
Re:Pointless Apology (Score:4, Insightful)
To say there is not path to forgiveness is a bit implausible, but this "apology" sure doesn't meet the threshold. A genuine apology includes appropriate amends.
Re: (Score:3)
Let’s be clear what happened here: Multiple incorrect patches were sent deliberately. This was not "one mistake". These facts were clear from the first story. I could classify your statements as misrepresentations at best.
However you seem to think that deliberate bad actions are entitled to forgiveness. "I know the guy tried to stab you on numerous occasions and missed: Why won't you forgive him for one mistake?" That is how you sound to me.
So sorry. (Score:3)
I'm sorry. [youtu.be]
"The Research" (Score:5, Insightful)
and the research says:
Trust Broken.
Re:"The Research" (Score:5, Insightful)
Ain't no coming back from that, banned for life, every person involved and a ten year ban on the university. They were trying to be dicks, trying to make a name for themselves, get themselves memed.
They admitted it, so honestly report it to the FBI as attempted fraud, the harm, what would have happened if it had gotten through, the cost of assessing broken software as broken, all ad up to damages, ACROSS A COMPUTER NETWORK, which makes it a criminal act and the Linux Kernel team should make an example of them by reporting the attempted fraud to the FBI and seeking criminal prosecution of the individuals involved.
They must take action to warn others off, else they will end up flooded with that rubbish. Fraud was attempted and it should be prosecuted.
Re: (Score:3, Insightful)
Re: (Score:2)
I thought cancel culture was bad. Now you want to cancel an entire university, forever, because of one mistake that some students made and apologised for?
Wasn't their little research project approved by their educational institution?
Re: (Score:3)
Cancel culture my ass. Its called "actions have consequences", and it's been happening for years.
People spewing "cancel culture" are just pissed off the world isn't letting them get away with their bullshit any more. They're tired of people calling them out for who they are and what they've done and then having to suffer the consequences of their own actions. Fuck em.
I would never trust a line of code coming from that university again. For life.
Re: (Score:3)
I've never witnessed a bigger masturbatory fantasy. You really want to start pinning damages on shitty code? Oh like that won't backfire.
Re: (Score:2)
You really want to start pinning damages on shitty code?
Yes, please. For example, anyone who writes an SQL injection bug is negligent. There are techniques to avoid that.
Re: (Score:2)
Re: (Score:2)
Yes. Code, as critical to the function of society as it is now, should be held to the same standards as any other engineering. Kill off all the negligient early releases, and the "Oh, not my problem any more" mentality. Make software engineers be held to engineering standards and ethics, both for safety and for privacy.
If you object to that, you are part of the negligence culture that infests software development like a cancer.
Re: (Score:2)
You really want to start pinning damages on shitty code?
In short, yes.
However, only code you pay for.
If you pay for OSS, then whoever you paid should be liable for the quality of the code.
If you're paying for customizations that should be obvious from your contract, and whoever you paid should only be liable for the quality of the code in the customizations.
There's no reason why the incompetent should be permitted to create insecure conditions for everyone else without repercussions.
Re:The higher path (Score:4, Insightful)
why are we pilloring the entire university for something that was done 6 months ago by 3 people?
It shows some real serious issues in both the management and ethos of the university that not only students but a professor thought it was OK to do something like this. That's an institutional problem.
Re: (Score:2)
we did that because we knew we could not ask the maintainers of Linux for permission, or they would be on the lookout for the hypocrite patches.
More like, easier to ask for forgiveness than permission.
Re: (Score:2)
It shows some real serious issues in both the management and ethos of the university that not only students but a professor thought it was OK to do something like this. That's an institutional problem.
Exactly. I can't believe they got it through IRB!
IRB review normally takes their time to review an interface evaluation survey (i.e., people come in, test a tool, and answer some questions). IRB approval process might still require some follow up.
This seems orders of magnitude above that, including the part where the subjects (people who reviewed the patches) did not know about the study.
Re: (Score:3)
Nope. They have been “moderated.” Their actions (and undoubtedly similar ones by other organizations) do not advance the open source community, so blackball them. They need to work for forgiveness— make them audit commits and judge if they could be nefarious. They are in the penalty box, and shall remain there until they have earned a reprieve.
Re: (Score:2)
Solomonic. I like it.
Re: (Score:2)
Re:The higher path (Score:5, Insightful)
The recent crop of poor patches was unrelated to the "hypocrite patches" paper
How can anyone tell it's not part of further research along the similar lines to the paper, other than their saying so? Remember, the university's review board let the original research go ahead. How can anyone but the people doing it know there isn't a new research project with similar methods, if not goals? It would be extremely stupid and negligent if someone in GregKH's position to assume they're unrelated.
It is NOT the Linux developer community's burden of responsibility to do independent review of every university's research programs. All of this HAS to work on trust or nothing gets done. So if you break that trust, once is enough, then it is YOU that has to carry the burden of proof of non-maliciousness.
Re: (Score:2)
Remember, the university's review board let the original research go ahead.
According to the paper, they got a "not human research" waiver rather than approval.
So, they mislead the IRB somehow. Perhaps IRB members did not realize that patches go through a human review?
Re: (Score:2)
6 months ago by 3 people?
Three people? When I did a research project at university there were >8 people involved. That's before I started counting myself or any of the actual people doing the project. I had professors, tutors, assessors, and an entire ethics committee. Better still I used the greater than symbol because these project pools got judged by the school of engineering and I honestly don't know how many people were involved there, but at the very least the dean of the school and a senior professor as well as likely a f
Re: (Score:3)
and why are we pilloring the entire university for something that was done 6 months ago by 3 people?
Because that's how you make stuff move. You can:
a. Send a strongly worded letter to the individual or the university. They probably won't give much shit and it doesn't prevent further problems from him or other team in the university or other universities.
b. Ban the individual. Individual is banned, may deter other individuals to do the same, but won't elicit a response or a change from the university.
c. Ban the university. You get a response within a day, and the university will make goddamn sure noone wit
Re: The higher acronym. (Score:2)
Re: (Score:3)
He's talking about the people who go to lengths to make excuses for RMS, almost none of whom have worked with RMS.
I see they are trying to ignore the other issue (Score:5, Informative)
> These 190 patches were in response to real bugs in the code and all correct â" as far as we can discern
It looks like they are still intentionally pretending the other problem doesn't exist - most of their patches do nothing at all. They don't fix any bugs. They just waste people's time.
They've been running an automated tool and send it the output as "needed patches" without *looking* at the output first. For non-programmers, it's kinda like running a grammar checker, which makes suggestions such as changing "it's not untrue that sometimes ..." to "it's true that ...", and then just "sometimes ...". That MIGHT be a better way to phrase it some cases. On the other hand, if the proceeding sentence is "the president said that people always", it may be the author really does want to point out that's not a lie.
Another example would be that C doesn't have the word "unless", only "if". So sometimes the clearest way to write something is to use a double negative, as a way of saying "unless":
If (not failed) ...
An automated tool trying to "simplify" the code by eliminating the double negative can easily be making it *harder* to read. You gotta actually look at what the tool is suggesting might be changed. Sending each one in without looking at it first is just wasting people's time.
Damage Control (Score:3)
I wonder if they switched to Social Engineering (Score:5, Insightful)
Phase II of their security test:
Public Statement: We are sorry. Please trust that the other things we submitted are safe.
Private Thought: Let's see if these fools will believe us.
Re: I wonder if they switched to Social Engineerin (Score:3)
Or perhaps they are doing Phase II which is a security culture test? Determining whether the Linux project is open and receptive to the blinded security audits, tests and research such this, or (as seems to be the case) whether it responds defensively like a whiny little brat.
Re: (Score:3)
IRB (Score:5, Insightful)
Our recent patches in April 2021 are not part of the 'hypocrite commits' paper either.
No, but that doesn't mean you weren't trying to do further research along similar lines for a newer paper. No one can tell, and in the interest of security, must treat all future attempts at contribution with suspicion.
Re:IRB (Score:5, Insightful)
As a wise man once said, "Speak softly, and drive a big tank."
Re: (Score:2)
Sadly, the image conjured up by your closing statement was the tank photo with Mike Dukakis. Ironic on so many levels...
Re: (Score:2)
I was imagining the Chieftan trying to fit inside a TKS [youtube.com].
Re: (Score:2)
Re: (Score:3)
Do we even know for a fact that the researchers in question submitted their experimental plans to the IRB? I've worked for a number of universities and research institutes myself, and while IRB review was technically required to do any research involving human subjects, the IRB did not have any proactive powers to police research groups. Rather, the IRB relied on thos
Re: (Score:3)
SJW
You lose.
Everything is SJW to you. You're worse than the SJWs you hate.
Re: (Score:2)
Re: (Score:2)
The existing contribution policies do not prevent this kind of act in the future, so banning is little more than a virtue signal.
Yeah, because updating the Code of Conduct to say "no hypocrite commits" isn't a virtue signal.
What isn't a virtue signal these days? It seems like being a complete and utter psychopath is the only thing that's acceptable to you nerds.
Comment removed (Score:4, Interesting)
Was there even a need to investigate this? (Score:2)
Re: (Score:3, Interesting)
What I don't understand is why they couldn't just look at historical introduced bugs that later got fixed, and just do research on that. Why the need to intentionally introduce new bugs?
Re:Was there even a need to investigate this? (Score:5, Interesting)
Life pro tip (Score:2)
An apology should be the first thing you send when you realize someone else seems hurt. Regardless of how justified you feel your actions were. An apology is not an admission of guilt.
Re: (Score:3)
Re: (Score:2)
admitting guilt is a large part of an honest apology.
It's also a large part of publishing an academic research paper. :)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I'm pretty sure he's talking about metaphysical guilt. Guilt on one's soul. And you are talking about more practical guilt. That is, if you drop a bowl of milk and you say it was your fault, I don't think he considers that "admitting guilt".
Re: (Score:2)
An apology should be the first thing you send when you realize someone else seems hurt. Regardless of how justified you feel your actions were. An apology is not an admission of guilt.
Absolutely wrong on all counts. Here's a nickel, get yourself a bookmark to a dictionary. And give me back my nickel, because bookmarking is free.
Apology means "a regretful acknowledgment of an offense or failure". It absolutely is an admission of guilt. You should not send an apology simply because someone else seems hurt. If you want more information and don't want to admit guilt you can send an acknowledgement that they seem hurt, and accompany it with a request for clarification.
We probably shouldn't ta
Mistakes were made, Lessons were learned (Score:2)
However, instead of actually making positive kernel changes, someone had an agenda, and they are receiving exactly what they deserve.
Now, if criminal charges are filed, someone's probably going to go to PMITA prison.
Which according to current law, is correct.
So, an apology may be analogous to a confession.
They changed their mind (Score:3, Informative)
Their first reflex was a call for cancellation. I think that only because of the quick and firm response by the kernel community this story wasn't picked up by some news site or medium blog and spun as a "mean geeks have no social skills" story. For now.
Easy (non)solutions (Score:3, Insightful)
How is banning the researchers solving the problem they exposed? If they can do it, so can other people, and for sure large state actors. So rather than focus on the actual problem, the public is pacified by the researchers being banned. Problem solved, right? Reminds of when a researcher gave a Blackhat presentation on NUL prefix browser https bug, he demoed it by impersonating PayPal. PayPal's response? "We banned the researcher from PayPal, problem solved".
Re:Easy (non)solutions (Score:4, Insightful)
It solves the individual problem of one person who doesn't understand that you don't break other peoples' toys without their permission. If you want to break your own toys, go right ahead.
The other systemic issues should be addressed separately.
Re: (Score:3)
There have been multiple slashdot posts on banning these guys, yet nothing on the solution you speak of. So please share a link to the upcoming solution to the systemic issue of malicious insertion of backdoors (yes, inserting vulnerabilities is inserting backdoors). It would make for much more interesting slashdot post, as that is the hard to solve problem at hand here - banning is easy but solves nothing, unless the problem is that you really believe the University of Minnesota was intending to do it agai
Re: (Score:2)
There have been multiple slashdot posts on banning these guys, yet nothing on the solution you speak of.
I think the problem is that there is no real solution besides more human review. Solutions such as updating code of conduct or solving understaffing by encouraging more people to join OSS maintaining seem underwhelming:
https://github.com/QiushiWu/qi... [github.com]
Re: (Score:2)
How is banning the researchers solving the problem they exposed?.
Ask yourself this. How is continuing to allow them to submit patches solving the problem? Creating a system where people volunteer to contribute puts ultimate responsibility for those contributions on the creator of that system. The creator of that system will then rely on "good faith" intentions just like any democracy, to help with the daily running of that system. Take away "good faith" then what should be the standard? The assumed privilege enjoyed by the contributor? In fact where does anything less of
Sorry... (Score:2)
Are they sorry they did it or sorry they got caught?
Smells like the latter.
"It was just a prank bro!" (Score:2)
"A literal experiment!"
Furthermore they added: "I love you baby!" (Score:2)
"You know I would never intentionally hurt you."
"Can you forgive me?"
Apology accepted.. (Score:3)
Aditya Pakki still getting his Ph.D, apparently (Score:2)
Nothing in the "apology" letter about this, other than he's a co-signer of said letter. An adult in a PhD program has this level of professional malfeasance doesn't deserve a degree, at least not for some good time of good-behavior shown.
Re: (Score:2)
Everyone knowingly involved, or anyone who knows now and continues to defend this behavior, should have their Ph.D.s stripped. Individually, if they recant and perform some atonement, they can keep the existing degree or, if they don't have one, can produce a completely new thesis and start again.
Whatever this was was not an honorable or ethical attempt at bringing the light of knowledge into the world.
Re: (Score:2)
On second thought, there's no way to know if anyone involved did legitimate work on their degree, so we need to revoke them all until they can prove they didn't doctor their doctorates (for the PI and so on).
Actual example of the old saying ... (Score:2)
Easier to ask for forgiveness than permission.
Re: (Score:2)
But the kernel is written in C, not Python.
They are self centered arrogant elites (Score:2)
Distillation... (Score:2)
Re: (Score:3)
Re: (Score:2)
In Soviet Russia, dynamite have to earn right to play in house with children.
Or something like that. It doesn't translate well into Yakov.
Re: (Score:2)
Heartbleed proved this to be true. Full of holes for years because everyone assumed that someone was looking.
Re: (Score:2)
Re: (Score:2)
Letting a university do this would send a signal to every other security researcher that it was okay to do this. Then all of kernel development would grind to a halt because they get inundated with hypocrite commits, or rather, troll patches.
The
Re: (Score:2, Insightful)
There aren't enough qualified developers and security researchers and the money to pay them for their time to analyze every bit of code in every patch for potential security issues.
That would imply the whole "many eyes" thing is completely bogus which is very unfortunate.
Instead of simply looking for bugs these developers and security researchers should instead be adding features to a code analyzer which can automatically detect more and more classes of bugs.
Re: (Score:2)
Look, the TSA does this on a regular basis, with inspectors attempting to bring fake contraband through airport security in order to test the competency of the system.
The TSA is for show. They make a big deal out of finding obvious shit people forget they had on them when going thru security yet are completely incapable of doing what most people think they are paid to do. When red teamed they had a 95% failure rate in 2015, 80% in 2017.
The problem with those commits wasn't that they were deliberately flawed. It was that they were deliberately flawed in _obvious_ ways that never stood a chance of security passing review, which might otherwise have revealed dangerous holes in the process.
There are untold thousands of innocently flawed contributions that created dangerous holes nobody knows about to this day.
Anyone who thinks they can create a process to detect and reject deliberately flawed patches is fooling themselves.