Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Banning the university is fine to send a message, but reverting all patches from umn emails seems very shortsighted to me. Especially blindly reverting patches years before this "research" was conducted that almost certainly have had context changes around them, likely introducing more harm than good.


I think that reverting them so that they can be reviewed is entirely appropriate - sure there are lots of people at that particular university, but it's not the linux maintainer's job to know which of them are bad actors - better that the entire university gets locked out, if only to get their attention, and then let them sort out their bad actors before being let back into the fold


I could easily see sending in a bad patch to see what happens and then waiting a few years to do more and write them up; there's no realistic way to guarantee when the bad-faith contributions started.


they are re-reviewing the patches and will be accepting them back if they look fine, it is not really blindly rejecting them all


And in the meantime allowing patched permissions vulnerabilities to reappear in mainline? Seems to be a bit of an overreaction no? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...


Except that patch is clearly BS! You can't patch a double-read vulnerability by checking for a capability; that's not a thing that works. So either the description is wrong, or the patch is wrong, or both.

And the point of the reverts is that the kernel maintainers don't have the unlimited time that would be necessary to re-review all of these questionable patches for probable malicious underhanded C, so they are reverted for now for triage (not permanently).

For the linked patch, I would judge it possibly malicious as it leaves the identified vulnerability in the kernel for later exploit by the attackers, namely, the UMN research team.


You don't think reverting a patch from someone whose only relation is working(worked?) at the same university as the advisor initially responsible for the security "research" is overkill? If the goal is to prevent security bugs in mainline then maybe haphazardly reverting everything that doesn't conflict and fixing it later isn't the best approach.

I'm disappointed at seeing hackernews jump on this mindless mob justice like other sites would.


Its a completely reasonable response. I'd say your point of view is the mindless one.


> I'm disappointed at seeing hackernews jump on this mindless mob justice like other sites would.

Having your patch reverted pending review is hardly punishment. Calling this mob justice is an insult to both mobs and justice.


Seems like the problem was from more than one person. This doesn't seem like mob justice, it seems like a pretty measured response to a source of repeat bad faith actors.


I don't think the removal of those patches means the changes will be immediately pushed to public. If they are breaking anything it is develop branch and surely they will review all those patches and will merge the good ones back before releasing anything public

edit: actually not even the develop I think https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh... It is just another branch? I am not familiar with the jargon




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: