It took 'over 80 different developers' to review and fix 'mess' made by students who sneaked bad code into Linux

Linux maintainer Greg Kroah-Hartman has sent in a pull request for Linux 5.13 aimed at dealing with grief caused by the antics of some students at the University of Minnesota. The fixes, for rc3 of version 5.13 of the kernel, included a terse note from Kroah-Hartman: The majority here is the fallout of the umn.edu re-review …

[Sparkus]

not just umn.edu

the suspect students and their faculty advisors list multiple affiliations, and most likely multiple email addresses and personae.

Given the 'open' activity from their umn.edu accounts, it's likely prudent to look at potential submissions from ALL of their IDs and persona, those that can be identified anyway.......

[Anonymous Coward]

Re: not just umn.edu

Making submitting bug fixes to an Open Source project prohibitively difficult would probably be the worst outcome of this debacle.

It's already annoying enough having patches ignored for months without being asking for bank account and social security details.

[rcxb]

Re: not just umn.edu

Those other identities / personas won't be "trusted" by the kernel developers, so there's no reason to worry about them. They were only successful because they were associated with a group that has been reliable and trustworthy in the past. Unless they have similar connections to other organizations, it's a non-issue.

[Anonymous Coward]

Re: not just umn.edu

And I wonder how much code is being sneaked in by the NSA and other 3/4 letter agencies?

Open Source seems to have descended into Open Farce.

[stiine]

Re: not just umn.edu

Do you consider IBM a TLA?

[bombastic bob]

Re: not just umn.edu

no... peer review is still possible.

[Version 1.0]

Re: not just umn.edu

If you are a student on the way to graduation what's the highest paid job opportunity, demonstrating that you can write open source code or applying to the NSA with the code in your hand?

[bombastic bob]

Re: not just umn.edu

right - significant peer review is in order.

Sad.

[doublelayer]

Re: not just umn.edu

They didn't do this for security. They do review all the PRs that get merged, so it's not a case of blindly trusting someone from a domain name. This is a method of indicating displeasure with the university. The university approved the study which they consider offensive, and they're hoping that the block on it will indicate to the interested parts of the university that the Linux kernel developers aren't pleased with what they did. Anyone at the university can still contribute by using a different email address. It's not in any way intended to be a security feature.

[Cliffwilliams44]

Re: not just umn.edu

The banning of the UNM email addresses was not just to punish the individuals but the University that approved the project. The board that approved this project are both idiots and incompetent.

It will be difficult for UNM to recruit new CS students with this ban in place and hopefully it will also impact their ability to garner financial support. One can only hope!

[The Man Who Fell To Earth]

Re: not just umn.edu

"It will be difficult for UNM to recruit new CS students with this ban in place and hopefully it will also impact their ability to garner financial support. One can only hope!"

No CS student worth their salt will give a crap, and it will have zero effect on their careers. No US funding agency will give a crap. None. Nada.

[Anonymous Coward]

Re: not just umn.edu

Yea, but never mind all of those from all those State Actors in China, US, Russia, Iran, UK, Israel, etc.

[oiseau]

The only sane thing to do

... "only merge things after verifying they are valid" should maybe be the default policy of the most used piece of software in the world.

Indeed ...

It is the only sane thing to do.

I was unpleasantly surprised (very) to learn that pull requests to the Linux kernel code were accepted solely on the basis of its provenance.

And I have an odd feeling that this was just an exercise to test the waters, so to speak.

The next time (if it has not happened already) it may well go unnoticed.

Like Doctor Syntax said when this was news here at ElReg:

"... remember that Linux gets used in a lot of places these days. It's critical infrastructure."

You. Do. Not. Fuck. Around. With. Critical. Infrastructure.

O.

[Anonymous Coward]

Re: The only sane thing to do

"You. Do. Not. Fuck. Around. With. Critical. Infrastructure."

The someone should tell Red Hat to have a sit down with Lennart and have the big boy pants talk again. The world relies on Linux as a server OS, he needs to stop treating it like his own personal desktop OS.

If you are thinking about introducing major breaking changes, ask first, then LISTEN. Building is the last step, not the first.

[DS999]

How to deal with Lennert Poettering

1) take up a collection of Linux users who hate systemd (i.e. 99% of us)

2) use the money to bribe Microsoft to hire him away from Redhat, he produces the kind of bloated crap they like anyway

3) have a team at Redhat tasked with deconstructing systemd and replacing it with modular scriptlets

[Warm Braw]

Re: How to deal with Lennert Poettering

Linux users who hate systemd (i.e. 99% of us)

As a member of the remaining 1%, I'm clearly unrepresentative but I could list a number of more fundamental faults that I might choose to fix, could I be bothered, before turning my attention to systemd.

However, I'd be sorry to see it go, given the immense amount of entertainment we've been gifted by the endless vitriol of the "99%" about a piece of software they don't pay for, are not obliged to use and are free to change as they see fit.

Unfortunately, the rest of our small minority probably can't raise enough money to get Microsoft to rewrite systemd in Powershell and submit it as a patch, but it would be worth it for the amusement value alone.

[KSM-AZ]

Systemd Was: How to deal with Lennert Poettering

The arguments against systemd . . . I recall very similar arguments during the infant days of linux. Something around a "micro-kernel" approach to kernel design vs the "monolithic" approach Linus took. Yes Linux was doomed to fail because Linus failed to to create the kernel using a modular design with a message passing system between modules. It's too bad it didn't work out for Linux, ummm. err.

The biggest difference ended up being with performance. Apparently a monolithic kernel with shared space was radically more performant than tossing objects around as messages. I believe concepts from both approaches are now integrated across both kernels. None-the-less I'm thinking there is a ton of monolithic linux code in the current tree.

Systemd is a natural progression. Personally I like Sysvinit. I like inittab and the RC stuff, but it has a number of scalability issues, that increasingly created performance and startup delays as the amount of crap to start up the system. Dependencies ended up with startup stuff running very linearly. Systemd is a very monolithic setup to handle the initialization of core system functions, and launch subsystems for other services. It's complicated, it's stabilizing, and it still very idiosyncratic, kinda like oh, i dunno Linux 0.95-2.1.

If you want to do an embeded project, I'd go with Alpine and OpenRC. Wanna run some apps on a tomcat or php, take your pick. If you want to integrate the servers with AD, or openldap, i'm going to run with systemd. And if you want a desktop and all the crazy dbus stuff I'm behind it 100%. Let's get rid of netplan.io, and get the network piece up to snuff and blow away 'NetworkManager'. I'm not thrilled with systemd-networkd, but it mostly works these days, and for a simple server install it provides a consistent target, albeit somewhat clunky for running KVM bridges and dozens of VLAN's. Too many config files.

If you despise it that much, nobody has a gun to your head. Use Mint or Alpine or something.

[martinusher]

Re: Systemd Was: How to deal with Lennert Poettering

I always thought that people trying to build code around a Windows-like services and message passing model were merely trying to implement the Wnidows facilities they know (and love) in Linux.

[Anonymous Coward]

Re: How to deal with Lennert Poettering

Downvoted, not because it's pro-systemd (I'm neutral in that fight), but because it considers "endless vitriol" to be entertainment.

[Anonymous Coward]

"use the money to bribe Microsoft to hire him away from Redhat"

Really no need, Windows NT always had a services system that was light years ahead the crappy Unix/Linux daemon implementation..... we can leave Linux people keep on fighting to get a modern services implementation... maybe around 2070 it will be understood.

[bombastic bob]

Re: "use the money to bribe Microsoft to hire him away from Redhat"

see icon...

'services' in windows NT (and later) were supposed to be like daemons in POSIX OS's...

* run in userland as background processes

* 'system' type of user context (root, other user)

* auto-start on boot or on demand

* managed by system utilities

without arguing against systemd [which I would] I question the validity of your comparison between windows and Linux and 'windows services' [which I've written] and the assertion that in any way the windows way is superior...

[Doctor Syntax]

Re: How to deal with Lennert Poettering

"use the money to bribe Microsoft to hire him away from Redhat"

What makes you think he isn't working for Microsoft?

[masterbaiter]

Re: How to deal with Lennert Poettering

This! I've always thought that Poettering - apart form being an unpleasant arrogant person - is an Open Source Saboteur.

[Paul Hovnanian]

Re: How to deal with Lennert Poettering

Windows already has a registry. Why would Microsoft need his help?

[oiseau]

Re: The only sane thing to do

... someone should tell Red Hat ...

... to stop screwing up Linux.

Poettering does as he is told.

Or do you by chance actually think that he has any sort of autonomy?

There is a saying in Spanish speaking countries which basically translates thus:

It's not about the pig, it's about the one who feeds it.

O.

@DS999: do you actually think that Microsoft and RedHat have different agendas?

[Gene Cash]

Re: The only sane thing to do

Poettering does as he is told.

You obviously haven't ever seen his posts. His "nyah, nyah, nyah, not hearing you!" is more renowned than Linus' swearing.

[Anonymous Coward]

Re: The only sane thing to do

Wow are you people still going on about systemd? That argument was over a long time ago.

Those massive copy-and-paste scripts gluing together the boot process? That isn't and never was "the Unix way". Go and look up what inittab did in SysV.

[martyn.hare]

People who whine about systemd..

Remind me of the same people who used to disable SELinux targeted policy because they couldn’t do 5 minutes of research on how to appropriately label files. Systemd solved a myriad of basic issues with service management (especially when interacting with automatic network mounts) and while it did have a rocky ride early on, it never got introduced to an enterprise distribution until most of the bugs were already ironed out.

Just about every distribution adopted it because it’s the best solution. Deal with it,

[dvd]

Re: People who whine about systemd..

The problem with systemd is that it was a fundamentally sensible idea implemented in a heavy handed way with a massive amount of over-reach by the most arrogant arsehole on the planet.

[Robert Grant]

Re: People who whine about systemd..

The problem with being hyper arrogant is that you turn people off so much that the only way for you to accomplish anything is to continue to be hyper arrogant. Otherwise people would ignore you and just listen to collaboratively minded experts who travel with them on a journey.

[sloanrb]

Re: The only sane thing to do

So the Linux patch validation infrastructure was so bad that a bunch of dippy college students was able to upload bad patches into the kernel.

Yes, what they did was bad, but why has no one called the Linux maintainers onto the carpet? Instead of them looking at their processes and find out what needed to change, they decided to come down on the entire University of Minnesota and punish them.

If this had been Microsoft that had punished the University everyone would be screaming bloody murder.

But apparently the Linux guys are held to the same standard.

[Snake]

Re: The only sane thing to do

Exactly! In this instance the Linux kernel got subverted by actors looking to test the system, and now the repairs are [only] being made due to the students admitting their actions.

But what if a subversion was INTENTIONAL? Say, by a enemy state actor who injects malicious code through a previously-trusted domain? Linux has just *admitted* that this process could be possible because the trust system for submittals is entirely location based. But they are too busy punishing the students... who identified this major security flaw.

[Anonymous Coward]

Re: The only sane thing to do

(1) The subversion was intentional, and presumably approved by the university.

(2) Bugs getting through review happens all the time, including security issues deliberate or accidental.

(3) These students did not identify anything that isn't known. Every CVE has an "introduced by change".

Frankly, these students are lucky they aren't getting a criminal record.

[Paul Hovnanian]

Re: The only sane thing to do

"Frankly, these students are lucky they aren't getting a criminal record."

Even worse. They are getting umn.edu on their CV.

[Anonymous Coward]

Re: The only sane thing to do

A criminal record? What for, submitting a dodgy pull request? I'm pretty sure that isn't a crime anywhere. If you deliberately and knowingly merged the subverted code I could see that being a problem but I'm pretty confident you're safe submitting shit code.

[low_resolution_foxxes]

Re: The only sane thing to do

I know it's open source, but frankly it's used everywhere and just imagine if it caused a fire/explosion/death. Could you imagine the lawyers chasing the ambulances?

That said, we're not talking playdoh here. I know Linux is a community project, but we're not talking a communist utopia. Linux is serious business behind the scenes of really important economies, if some kids can fuck it up for a laugh, without the scent of peer review, wtf is going on?

[stiine]

Re: The only sane thing to do

You should read th GPLv2.

[razza]

Re: The only sane thing to do

"actors"

that's why they ballsed it up. They had actors doing it instead of developers!

Put that the Agile book down, walk away from the desk... OK.

[doublelayer]

Re: The only sane thing to do

You may have a few misconceptions about what happened.

"So the Linux patch validation infrastructure was so bad that a bunch of dippy college students was able to upload bad patches into the kernel."

No. They wanted to do that, but realized the risks before getting that far. From the original article on the subject, here's a statement from one of the researchers describing how far they actually got:

The buggy patches, he explained, were sent via email and did not ever become a Git commit in any Linux branch because maintainers were informed after the fact so they would not move forward with the bad code.

Who knows what would have happened if the code was in a real PR and got through the full review. It might have gotten through, but we don't know that. It also could have been detected and thrown out.

People here are assuming that it got into the next release and subsequently pulled (it didn't) that the Linux kernel devs used to accept anything as long as it came from a umn.edu address (they didn't), that the changes got the full review that others would (they didn't), and that blocking the umn.edu domains is intended as a security feature (it isn't).

"If this had been Microsoft that had punished the University everyone would be screaming bloody murder."

No. If this had in some way happened to Microsoft, the students involved would be facing criminal charges of computer misuse. It's open source, and thus not criminal, but if it was Windows source, that would be illegal. It would have been significantly worse for the students and I would not be taking their side. As it is, the students wanted to test the Linux kernel, and the test isn't exactly useless, but A) they didn't actually run a useful test and B) if you test on people you don't know without informing them, you can expect them not to like it.

[Anonymous Coward]

Re: The only sane thing to do

I still have an active umn.edu account. I find it bemusing that thanks to this event, any submissions I make to the kernel will be rejected. I'm inept enough of a programmer that any of my submissions should be rejected anyway.

[Pascal Monett]

Sorry, but you are intelligent enough to be aware of your ineptitude.

That makes you better than a lot, in my book.

[low_resolution_foxxes]

I love that you apologised for complimenting them.

[Anonymous Coward]

Re: The only sane thing to do

Oiseau,

Like Doctor Syntax said when this was news here at ElReg:

"... remember that Linux gets used in a lot of places these days. It's critical infrastructure."

You. Do. Not. Fuck. Around. With. Critical. Infrastructure.

Linux is in a bit of a grey zone in this regard. The Linux kernel devs give absolutely no guarantees whatsoever on Linux's integrity, correctness, etc. And that is entirely fair enough, it's a volunteer OSS project. Thank you all who participate.

However, they do seem to want to be seen to be "doing things properly". And then the likes of RedHat layer their own veneers of professionalism on top, but they also pass on the same license exclusions about reliability, and so forth.

So the people owning all the risk where it's used in critical infrastructure is the owners of that infrastructure. I'm one such person.

And I agree, I don't particularly care for how this whole thing has been handled. I'm not going to complain to the kernel devs about it due to the inevitably of the conversation about aforementioned license terms and conditions and volunteer status.

However, it's incidents like this that give RedHat and Ubuntu a serious problem. Thus far they have more or less stayed in lockstep with the Linux kernel project, though RedHat do do a lot of their own kernel maintenance. Thus far that lockstep has been OK. But what do they do if the Linux kernel project disintegrates?

My biggest concern in this regard is that RedHat decide to decouple their tree from the remnants of the Linux kernel project and go it alone. Which potentially means Poettering gets to control it. And it wouldn't be long before Ubuntu are forced into following suit as other projects like Gnome and Systemd start requirimg a RedHat kernel.

What's the likelihood of that outcome? I reckon it comes down to how long Linus Torvalds stays in charge. He can be a deeply unpleasant person, but he does have a tight grip on the Linux kernel project. With him gone, it could be mere months before there's a breaking schism with Lennart leading the pack with the heaviest club.

Now that really is a future to plan for and avoid.

[Doctor Syntax]

Re: The only sane thing to do

"it's a volunteer OSS project"

It seems we have to keep repeating this: there are published statistics on who contributes most to Linux. The main contributors are inevitably corporate. It's in Intel's interest, for instance, that their products are supported so they're always there are thereabouts at the top of the list. From memory Google and Red Hat are also leading contributors.

It's a lot cheaper for someone who needs an OS kernel that can be almost met by Linux to take it and tweak it than to develop from scratch and it's also cheaper to contribute their changes back than to have to keep applying them to every new version of the kernel.

It's called collaborative development.

[Anonymous Coward]

Re: The only sane thing to do

Sure, but I don't think that dilutes the point. The corporates voluntarily cooperate with the kernel project admin'ed by Linus Torvalds. One day that may change.

[Phil O'Sophical]

Re: The only sane thing to do

You. Do. Not. Fuck. Around. With. Critical. Infrastructure.

But ill-intentioned people do, all the time. If it's that crititical it's up to the maintainers to make sure that You. Cannot. Fuck. With. It.

You wouldn't expect a bank to allow random strangers to submit financial transactions, even if you could revert them if/when they were detected, so why should the OS that the bank systems are running on be treated any differently?

[eldakka]

Re: The only sane thing to do

> I was unpleasantly surprised (very) to learn that pull requests to the Linux kernel code were accepted solely on the basis of its provenance.

But that's true of anything. The validation process is merely another source of provenance. You are just changing who's provenance you are trusting, that is, you are now trusting the provenance of whoever is doing (or wrote) the validation process.

You can't get away from that, at some point you are trusting someone's provenance, whether it be that of someone who peer-reviews the pull request, or the people who wrote the code that does an automated validation (can you trust the people who wrote the compiler or the standard libraries?).

The best you can do is reduce the number of entities who's provenance you implicitly trust, you can't eliminate it entirely.

[JimC]

I dunno, while locking the stable door after the horse has bolted is not actually a bad thing, this feels like locking the stable door the horse exited *while leaving all the other stable doors as they were*. There are a lot more and a lot worse bad hats in the world than these dumb students. Its hard to believe that no-one else has done the same thing,

[Tom 7]

In almost all forms of development co-operative development structures - ones that assume no malice - are orders of magnitude faster than those that assume malice. In many ways kernel development has been lucky that no-one has tried this before. The effort involved in back filling the development process with mechanisms to ensure this doesnt happen again would be considerable.

Interestingly the people who are going to suffer most are the new chip/ concept developers.

SystemD will find it much much harder to get new 'features' added. Bug fixes like the dreaded buffer overflow will probably be easy to check and approve by normal methods.

[Doctor Syntax]

"SystemD will find it much much harder to get new 'features' added."

Hope springs eternal!

[Ace2]

80 devs

This was 80 devs tasked with reverting and reimplementing all of the (correct!) changes that had been posted from umn addresses? The vast majority of those would have been from people with little-to-nothing in common with the bad actors beyond an email domain.

To me it looks like a massive waste, but with what I’ve seen from GKH he’s enough of an arse that I’m not surprised.

[stiine]

Re: 80 devs

the umn.edu domain is not comparable to the gmail.com domain, nor (really) the hotmail.com domain. its more like theregister.co.uk.

[-tim]

Student loan refunds?

The US Dept of Ed has a program where a student can ask for a cancellation for student loans from Universities that don't deliver what they claimed. As this incident has made degrees issued by that department nearly useless, could all their current and many of their past student now ask for their student loans to be canceled?

[Ken Moorhouse]

Re: Student loan refunds?

Having to put "University of Minnesota" in the education section of your CV is punishment enough, perhaps?

There are however, proverbs about learning and making mistakes which could be construed in a positive light. It is the *learning* aspects of those sayings which is the crucial part, at the end of the day.

[doublelayer]

Re: Student loan refunds?

There are not many people who will even know this happened, and most who do are smart enough to realize that you can still learn a bunch of valuable computer science stuff without having anything to do with the project. The really smart ones will just check if the applicants were on the paper, which they're almost certainly not, and treat the university as they would have already.

[Jonathon Green]

So a bunch of people from a University did A Stupid Thing, the Linux Kernel team apply collective punishment to an entire University, and then it turns out that the Kernel team’s review and QA processes (the things the silly people at the University were purporting to test when they did The Stupid Thing) seem to have holes you could drive a bus through….

Even allowing for the unpaid volunteer status of many of those involved, and the bad faith actions of a few of them this doesn’t look good for anyone…

[Joe W]

Unfortunately I feel you are right. Was it a stupid stunt? Sure. However it did (apparently) prove exactly their point. The commits were accepted. Yes, revising /checking other people's code is hard work. I know. I force my colleagues to do exactly that, also with my code, and boy did we find stuff (also in my code). It is necessary though. Could I do it for the Linux kernel? No way. It is written in the wrong language for me, and I'm not a good enough programmer to do this (by quite a bit).

So: thanks to the gals and guys doing the hard work! I'll need to start contributing again through a translation project or so.

[Anonymous Coward]

The commits were not accepted in this case.

[A.P. Veening]

I strongly recommend you re-read the story, this is about the accepted commits. The unaccepted were no problem.

[Anonymous Coward]

I can read... The actual attack patch was rejected. The story refers to other patches submitted by the the University.

[ChrisC]

Exactly, but if it hadn't been for the attack focussing attention on *all* commits coming from umn.edu, how many of these previously-accepted-but-now-rejected commts would *still* be present in release builds?

Which begs the question - if these now-rejected commits are bad enough to need removing now, what went wrong with the review process originally to allow them to be accepted?

Which begs the follow-up question - what *else* has slipped through the review net and made it into the release branch?

The university went about this the wrong way, no question about it. But isn't it ever so slightly embarrassing for the Linux gatekeepers that, had it not been for this research project shining a light on everything the uni has contributed to Linux so far, those earlier bad commits would still be present. People are right to be pissed off at the uni for the rather anarchic way in which they performed the research. But let's not kid ourselves that the uni is the only problem here...

[doublelayer]

"Which begs the question - if these now-rejected commits are bad enough to need removing now, what went wrong with the review process originally to allow them to be accepted? Which begs the follow-up question - what *else* has slipped through the review net and made it into the release branch?"

These are important questions, but not really new ones. We know that bad code gets into Linux all the time. They have to keep fixing bugs and security holes and each of those got in at some point. They have decided that speed takes precedence over a very long review sometimes. A useful study would look at the largest bugs and track back to the review which should have caught them. They could identify patterns where the reviews are insufficient. That would have made a lot of sense, but it would also have been a lot more work than committing buggy code to see if the process which has let in errors before lets in errors for the 2684th time.

[Anonymous Coward]

I would argue that the entire computer science department at this University "Did A Stupid Thing". Possibly extend that upwards to management.

Deliberately inserting malicious code into computer systems without permission is a crime. A University needs to have a system to ensure their research is conducted legally.

So yeah - it's not about a bunch of random kids at a University. It was an official University-approved research project (and not a particularly insightful one at that).

[stiine]

but it was inciteful...

Yes, that's my coat...

[Ken Moorhouse]

Those saying that this is a reason to distrust Linux...

...need to bear in mind that disruptive influences could infiltrate any organisation, regardless of that organisation's legal status. We're currently seeing this happen with Nominet for example. It could happen to Microsoft, Apple, Amazon, Google, Facebook, etc. etc... The only difference, in some instances, is that it could conceivably end up having a positive effect, if it were to happen.

[Tom 7]

Re: Those saying that this is a reason to distrust Linux...

You may be onto something there. I know of several people who were paid by MS to not work for other companies. They dont really work for MS on anything useful - they are given a sandpit and lots of resources and a good living to keep them amuses but MS has no real use for them. I guess many other large companies do the same. I wonder if they keep them in their sandpits or let them do 'something useful' when they realise they are merely being kept unproductive on purpose.

[Anonymous Coward]

Re: Those saying that this is a reason to distrust Linux...

Anyone whose opinion even remotely matters already knows about the "get hired in the company and insert a backdoor" attack. It's what security services are paid to do.

That these students were allowed to break the law to "test" something that has been documented to happen a million times before is insane.

[Pascal Monett]

Break the law ?

What law ?

Nobody's going to jail over this. This is not a situation where the police are involved.

Maybe they should be, but that's an entire other argument.

[Anonymous Coward]

Re: Break the law ?

In the UK at least, this would be classified as "unauthorised use of a computer system". Which is a criminal offence. It becomes unauthorised the moment you lie about the purpose of the patch that you are posting....

And yes, this is definitely the sort of thing that the FBI investigates regularly.

[Anonymous Coward]

Re: "unauthorised use of a computer system"

Emailing someone a PR is not "unauthorised use of a computer system", making your code pullable isn't "unauthorised use of a computer system", the linux devs pulling your code isn't "unauthorised use of a computer system".

Where do you think the "unauthorised use of a computer system" happened, exactly?

[Anonymous Coward]

Re: "unauthorised use of a computer system"

LOL - if you accept emails from me, you are granting me permission to send you email. If I lie as to what is in a pull, that is "fraud" and what the code actually does is "unauthorized".

[KSM-AZ]

Breaking the law Was: Those saying that this is a reason to distrust Linux...

In particular what law was broken in what country? I sent a bogus patch up to a git repository you stuck it in. Caveat Emptor. Something about fitness for a particular purpose comes to mind.

[Anonymous Coward]

Re: Breaking the law Was: Those saying that this is a reason to distrust Linux...

It's called the "Computer Misuse Act". It's extremely broad, and covers any time you deliberately make a change to a computer system that is not agreed to by the owner of that system.

If your patch doesn't do what you say (needs to be deliberate) and someone runs it, you are using their hardware in a way that they do not agree to.

[Someone Else]

Re: Those saying that this is a reason to distrust Linux...

Those saying that this is a reason to distrust Linux...need to bear in mind that disruptive influences could infiltrate any organisation. [...] It could happen to Microsoft, Apple, Amazon, Google, Facebook, etc. etc...

Is it you're assertion that "disruptive" influences haven't already happened to Micros~1? I submit Windows 10 as Exhibit A...err, wait...make that Exhibit V...that Micros~1 is in and of itself a disruptive influence.

But I digress...Back to slamming systemd.

[Danny Boyd]

There is a word for it:

"Clusterfuck".

[steelpillow]

The art of the possible

Sure it would be nice to validate all the Linux code before it goes live. But sheesh! Have you ever tried to validate anything? Now scale that out to the kernel patch ecology. Maybe roll out the next build in the fifth Universe down the line, certainly not in this one.

So something has to be taken on trust. Email domains sounds like a loose recipe for disaster - and it has turned out to be just that. Individual user accounts, vouched for by an existing trusted user, might be a reasonable middle ground.

[Anonymous Coward]

How about blind matching dev and reviewer

What the devs and reviewers are not matched randomly and without each one not knowing the other and develop two commiters logic similar to four eyes in security systems. Instead of domain based trust would be unattended and more effective way of commiting changes.

[niio]

Banning UNM.EDU is not enough

The University needs to be sued for monetary damages sufficient to force the oversight board to change their policy, and to put every other institution on notice that the same awaits them for bad behavior.

Tightening up the review/commit process is a separate issue. This is why we can't have nice things.

[Anonymous Coward]

Automated testing..

A proper automated testing regime would help to alleviate these kind of shenanigans.

Eyeballing changes isn't enough.

I used to work at a place that regression tested every change on hundreds of hardware types. Should be possible to do by one of Linux' corporate backers.

[Anonymous Coward]

Re: Automated testing..

I'm a bit surprised that there are people who are still against automated regression testing, but perhaps less so that they are unable to articulate their objections.

[daniel-wu]

I am shocked with the last Tweet from Filippo Valsorda. Does this mean Linux has blind trust on every students from umn.edu? No proper review before they make it into production??

[ForthIsNotDead]

Yes. If you are known to the maintainers and they trust you, whatever you submit is blindly accepted on faith. If you, meanwhile, have been paid by, say, China or the CIA or the FSB to slip something nasty into the code, there's no way they could know, because they don't check your code.

They may 'review' it to check that you're not doing something really dumb, like using old, deprecated system calls, that sort of thing, but other than that... Help yourself.

[sreynolds]

Its more and indictment of the current state of the kernel.

Too many cooks cooking soggy spaghetti that dries into a single monolithic.

[Joe Dietz]

Stop ragging on the students... they obviously hit a nerve

The proposition was 'is Linux based entirely on reputational trust or... some set of security oriented objective review criteria'. Turns out it was the former and nobody likes being called out... But they did us all a big favor in pointing out the disconnect between the actual culture and the actual thing that should be happening. This is an obvious weakness with the open source model and the Linux kernel is by no means the ONLY thing that can be subverted here.

[martinusher]

I do feel that someone's laying it on a bit thick....

The whole point of a code archive is that you can rapidly identify who/what/why/when and manage changes both before and after they're committed. Maybe there's something different about the Linux archive but in the world I'm used to it would have been relatively straightforward to revert to a particular build or date and discard any changes entered after that point. I'd also expect individual developers to keep their work backed up so that they could identify their contributions and re-submit them. All routine stuff, the sort of thing I'd have done while gulping the first coffee(s) of the day.

Let me guess - Linux uses a more advanced archive system......

(Also -- Linux is supposed to be 'modular', isn't it? It's been looking (and behaving) very Windows-like in recent years. Is there a reason for this or is that people just like building huge blobs of code that have numerous documented (and undocumented) dependencies between the components?)

[Anonymous Coward]

Re: I do feel that someone's laying it on a bit thick....

Windows is modular, certainly more so than Linux.