Announcement

Collapse
No announcement yet.

Vandalizing Open-Source Drivers?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Vandalizing Open-Source Drivers?

    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 "[email protected]."..

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    That was remarkably unnecessary.

    Comment


    • #3
      I lol'd. Should've kept it.

      Comment


      • #4
        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.

        Comment


        • #5
          Originally posted by Plombo View Post
          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?

          Comment


          • #6
            Originally posted by libv View Post
            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).

            Comment


            • #7
              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.

              Comment


              • #8
                Originally posted by libv View Post
                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.

                Comment


                • #9
                  Originally posted by crazycheese View Post
                  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.

                  Comment


                  • #10
                    Originally posted by libv View Post
                    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.
                    We have a security talk here
                    Trust is a weakness. (C) introversion

                    Comment

                    Working...
                    X