• FauxLiving@lemmy.world
    link
    fedilink
    arrow-up
    30
    ·
    26 days ago

    If you’re not familiar with reading mailing lists or don’t follow what is happening, Brodie Robertson on YT did a good video on this: https://youtu.be/GhfhzTDQdUU

    TL;DR: Some tooling script caused the problem, but it initially seemed like a malicious pull request from kernel developer. It wasn’t and the issue was resolved. The tooling script will be updated with better error messages so this kind of problem should be obvious when it occurs.

  • squaresinger@lemmy.world
    link
    fedilink
    arrow-up
    23
    ·
    26 days ago

    I got weirdly invested in this, and by the end I was kinda happy that it was “just” a bug in the tooling and not anything actually malicious.

  • Eager Eagle@lemmy.world
    link
    fedilink
    English
    arrow-up
    18
    arrow-down
    1
    ·
    26 days ago
    > Welp, that precisely recreated it -- even identical shas! Looking at
    > the b4 output, I do see a suspicious "39 commits" listed for some reason.
    
    Well, that's the point where the user, in theory, goes "this is weird, why is
    it 39 commits," and does Ctrl-C, but I'm happy to accept blame here -- we
    should be more careful with this operation and bail out whenever we recognize
    that something has gone wrong. To begin with, we'll output a listing of all
    the commits that will be rewritten, just to make it more obvious when things
    are about to go wrong.
    
    > So, I assume the "git-filter-repo" invocation is what mangled it. I will
    > try to dig into what b4 actually asked it to do in the morning...
    
    Thanks for looking into this. Linus, this is accurate and I am 100% convinced
    that there was no malicious intent. My apologies for being part of the mess
    through the tooling.
    
    I will reinstate Kees's account so he can resume his work.
    
    -K
    
  • 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍@midwest.social
    link
    fedilink
    arrow-up
    16
    arrow-down
    3
    ·
    26 days ago

    I’ll say here that one of the less discussed differences between git and Mercurial is that Mercurial does not allow commited history to be changed, and git does. Git users call this a “feature,” and it leads to situations like this which are utterly impossible in Mercurial.

    Git allows rewriting history by design. The kernel team uses it liberally. It is debatable whether this is a good thing, but it’s one reason I stick with Mercurial.

      • phantomwise@lemmy.ml
        link
        fedilink
        English
        arrow-up
        4
        arrow-down
        1
        ·
        26 days ago

        Anubis is an anti bot protection measure that gives your browser a proof-of-work challenge to solve before giving you access to the website. When I opened the link the website briefly showed Anubis but the anime girl mascot wasn’t there 😭

  • just_another_person@lemmy.world
    link
    fedilink
    arrow-up
    6
    arrow-down
    2
    ·
    edit-2
    26 days ago

    WHOOOOOA. If Linus is not mistaken (doubtful), there wasn’t an intrusion in the repo, or there wasn’t some fucked up merge somewhere, this is crazy as hell. This is a huge deal. Good on Linus for catching it.

    • floofloof@lemmy.ca
      link
      fedilink
      arrow-up
      13
      ·
      26 days ago

      If you read the whole thread, it turns out to be an undesirable behaviour of a tool called b4, which was rewriting not just author information but committer information. The consensus seems to be that this tool needs to be updated not to do that.

    • jdnewmil@lemmy.ca
      link
      fedilink
      arrow-up
      14
      ·
      26 days ago

      They are a record of the process of adding to the Linux kernel. Such background can be used to trace the history of contributions if those contributions turn out to have had malicious intent or were derived from code that came from sources that were not compatible with the GNU license that the kernel is released under.