Holy shit, I also got into crocheting last week. I have, however, managed to entirely avoid any hobby drama so far, but of fucking course this one is also being thrown into the fucking AI meatgrinder, ugh money people are so smart, man

tbc I’m not a mysticist at all, and I generally understand and agree with the historicity arguments. I haven’t read Ehrman, though. Do you know if his work is where does the “end-is-nigh witch doctor” idea comes from? Afaik neither Paul nor Josephus nor Tacitus describe him as such, and as I understand those are the main sources we have. Like, I can understand that this is a hypothesis someone floated around but I’m curious why this would be the consensus among historians.

I agree, yeah, this is definitely a git flaw and it should be fixed by git devs. There is no legitimate use case for a ref that looks like a hash, and the behavior should be the other way around: check if it’s a full hash first.

Fwiw a similar problem is well-known in e.g. GitHub Actions even without this confusion.

You can have your GHA scripts use “actions” written by other people, and the way you refer to them is user/repo@commit, where the commit can be a commit ID or a branch name or a tag name. The docs actually recommend pinning to commit IDs, but in practice most people actually pin to tags, like bob/doit@v1 because that will auto-update if bob fixes some bug and updates v1 to point to that. But if bob goes rogue, or gets compromised, the attacker could change the tag v1 to point to a malicious commit, though, hence the recommendation to use commit IDs for all actions that you didn’t write yourself. I don’t know if this ref/ID confusion can be exploited on GHA, but I would expect the answer is no, because GitHub Actions doesn’t launch git shell commands like a savage, but idk

You’re right that this can affect everyone, but there are different likelihoods of falling into the trap.

Humans are unlikely to issue checkout commands with commit IDs, plus git does issue a warning when a ref name is ambiguous like this. We just use ref names almost exclusively in normal workflows, with commit IDs used only if you’re doing some kind of debugging or audit, but even then git has tools that let you avoid that (bisect, “parent of X” refs, etc)

So that leaves mostly automated stuff. Lots of things that rely on git behind the scenes don’t just go out and invoke the git binary, they use something like libgit2 and (depending on programming language) this will have typed interfaces that prevent treating a commit ID as a ref name and vice-versa. So something like let c = Commit::new(pin); repo.checkout_commit(c); (I haven’t actually used libgit in a long time, this is illustrative, not real code) will never fall into this trap.

This is why LLMs are more likely to fall into this than other software, because it’s all ducktaped together and they run shell commands like savages.

My understanding is that the weakest link here is either git or the way the agents rely on git.

So, every commit in a git repository has a unique*, immutable, deterministic identifier. A commit with different content would have a different identifier. It is commonplace to use these identifiers to pin a dependency to a specific commit.

In addition to these immutable deterministic identifiers, there are also so-called “refs”, which are mutable identifiers. You use these to point to e.g. “the most recent version”.

So if the agent needs a “skill” that is pinned to the commit with ID aaaaaaaaa it will run the checkout command with that ID; this should prevent any shenanigans because only* a commit with the specific content that was vetted earlier will have that ID.

This attack exploits an unexpected git behavior: the command to checkout a particular commit accepts either a commit ID or a ref, but tries refs first. So what the attacker does is add a ref to the repository named aaaaaaaaa that points to the malicious commit. Then the agent runs git checkout aaaaaaaaa and ends up at the malicious commit instead of the one that was pinned.

I don’t know if there’s a way to tell git checkout to ignore refs, but this might actually be a vulnerability in other systems that rely on git for this sort of pinning.

* to an astronomically negligible probability of the contrary, and ignoring potential cryptographic breaks

I am now convinced it is indeed fake. Shame on me, posting slop

Presented without comment