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.

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

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