Vandalizing Open-Source Drivers?

[phoronix]

Phoronix: Vandalizing Open-Source Drivers?

Somebody with root access to the FreeDesktop.org server decided to vandalize the RadeonHD graphics driver in this Git commit. The make files were deleted and replaced with "It's dead, Jim" and a Git commit message line of "PERHAPS BONGHITS WILL FIX MY MAKEFILE." The supplied email address was "root@jerkcity.com."..

http://www.phoronix.com/vr.php?view=ODgxNw

[pingufunkybeat]

That was remarkably unnecessary.

[Plombo]

Interestingly, the email address comes from the website of Jerkcity. Jerkcity is a webcomic notable enough to have a Wikipedia page. One of the characters is named Spigot (the name of the committer). Spigot is even based on one of the authors of the strip.

Of course, it's likely that the vandal has nothing to do with Jerkcity, and simply spoofed his name and email address as a bad joke. He's already shown he's very good at covering up his tracks - as Luc noted, he disabled the update hook before his commit and re-enabled it afterward so that no email would be sent to the mailing list.

[libv]

Interestingly, the email address comes from the website of Jerkcity. Jerkcity is a webcomic notable enough to have a Wikipedia page. One of the characters is named Spigot (the name of the committer). Spigot is even based on one of the authors of the strip.

Of course, it's likely that the vandal has nothing to do with Jerkcity, and simply spoofed his name and email address as a bad joke. He's already shown he's very good at covering up his tracks - as Luc noted, he disabled the update hook before his commit and re-enabled it afterward so that no email would be sent to the mailing list.

The real question is: who would trust his code to fd.o after this?

[stikonas]

The real question is: who would trust his code to fd.o after this?

The relief is at least that git is quite good at detecting this. When writing git Linus Torvalds wanted to ensure that malicious 3rd party cannot change anything but the HEAD (which is easy to spot).

[stikonas]

And even if rebasing published repositories is not recommended, in this case it is probably a good idea, there is no need to tolerate vandalism even if the project is not thriving.

[tettamanti]

The relief is at least that git is quite good at detecting this. When writing git Linus Torvalds wanted to ensure that malicious 3rd party cannot change anything but the HEAD (which is easy to spot).

There's no magic wand shipped with git If you known the sha1 of a given commit you can check the entire history from that point back to day zero (since the IDs of the parents contribute to the hash of the commit); this basically ensure the integrity of the repository (short of a preimage attack on sha1). However this case wasn't an attempt to modify an existing commit, rather it was a "legit" commit (though on separate branch) that was only spotted by a human. Now, the message was clearly suspicious but through direct access to the repo you could sneak in a commit that looks plausible (e.g. maybe coming from another trusted developer) but contains malicious code; sure git push will warn you but you might overlook that change (for example when pulling stuff at work I don't inspect closely commits coming from trusted colleagues - though I do review stuff from interns or students).
Morale of the story: if an untrusted party has direct access to the repo it's game over

[crazycheese]

The real question is: who would trust his code to fd.o after this?

I think the answer more about improving security based on happened attack vector(hacker way) rather than panic (girl way) or inductive criticism(bad politician way).

The event is a good training exercise for security.

[libv]

I think the answer more about improving security based on happened attack vector(hacker way) rather than panic (girl way) or inductive criticism(bad politician way).

The event is a good training exercise for security.

This is not a security thing, it is a trust thing here. Those people with root access to the fd.o servers should be fully trusted, if not, they should not have such access rights. This event here clearly shows that one person should not have been given access rights, even when this person might have had this since right after the xfree86 fork.

[Smorg]

I lol'd. Should've kept it.