Have a sneer percolating in your system but not enough time/energy to make a whole post about it? Go forth and be mid - welcome to the Stubsack, your first port of call for learning fresh Awful you’ll near-instantly regret.
Any awful.systems sub may be subsneered in this subthread, techtakes or no.
If your sneer seems higher quality than you thought, feel free to cut’n’paste it into its own post — there’s no quota for posting and the bar really isn’t that high.
The post Xitter web has spawned so many “esoteric” right wing freaks, but there’s no appropriate sneer-space for them. I’m talking redscare-ish, reality challenged “culture critics” who write about everything but understand nothing. I’m talking about reply-guys who make the same 6 tweets about the same 3 subjects. They’re inescapable at this point, yet I don’t see them mocked (as much as they should be)
Like, there was one dude a while back who insisted that women couldn’t be surgeons because they didn’t believe in the moon or in stars? I think each and every one of these guys is uniquely fucked up and if I can’t escape them, I would love to sneer at them.
(Credit and/or blame to David Gerard for starting this.)
(OT: 🎶 Do you remember…)
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.
@rmf I’m not disagreeing with any of that. This is definitely a class of mistake (let’s be generous and call it that) which LLMs are more likely to make than humans in normal circumstances.
But it’s being touted around as an LLM-specific flaw which it isn’t. They do have their specific weaknesses, prompt injection of course still being a major one (e.g. Meta’s AI being persuaded to gzip & copy over its entire filesystem). But this is, if anything, a weakness in git. And I guess not entirely new, either, given that Github (and maybe other hosts) explicitly prevent users from creating a ref that looks like a SHA.
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.