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

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

Presented without comment

It really baffles me how these types manage to read this stuff so badly. The galactic holocaust at the end of Fire isn’t an accident, it’s the whole plan of the Powers from the start. There’s a fungus growing in the Top of the Beyond that might threaten them and their cure is to cauterize an entire slice of the galaxy, a plan which comes to fruition as intended. The final transmission implies that maybe some Powers got burned too, which might or might not have been the plan (the Blight was found in the Low Transcend after all) but the Beyond being burned was never optional, it was the plan.

The Blight is a big threat but it’s not even the first such threat in the galaxy; it doesn’t threaten the entire galaxy, not even the entire Beyond; heck, the only reason the extermination fleet travelled all the way to the Bottom was the pursuit of the entities working to enact its destruction. It can easily be argued that the cure was worse than the disease. Ravna outright thinks that at the end, it’s right there in the text.

I don’t even know why I’m arguing this here. These types just make my blood boil with how badly they misread (not misinterpret) works that I really like. Ugh.