James Endres HowellUhhh, guys? This looks real bad
"GNU Emacs: Multiple Remote Code Execution Vectors on File Open"
https://github.com/califio/publications/blob/main/MADBugs/vim-vs-emacs-vs-claude/Emacs.md
cehteh@jameshowell nice find, but looks more like an git issue to me. emacs is the culprit as it executes `git ls-files` but a user can do the same and wont expect that this executes attacker controlled scripts. Other IDE's probably also calling git ls-files.
The suggested fix is also overly specific. other git mechanisms execute scripts stored in .git too (hooks, diff/merge engines, signing).
Bottom line is: clone git, don't ship/touch/unpack untrusted archives that have a .git included.
Thomas@cehteh Ni, this is an Emacs problem. It's the one calling git unprompted. If it can't do that safely, it's up to Emacs to not*
Arguable that cripples the usefulness (anyone checked #Magit, may have the same problem).
The suggested fix is inadequate at least.
A rather drastic fix would be that git itself maintains a list of trusted repositories (the ones it cloned or initialized itself), plus a UI to add/remove/gc from this list. then only executing content from these .git's and rejects everything else.
One could implement that for emacs alone, keeping a list of trusted git repos and reject git on untrusted one. But thats not a fix on the root of the problem.
@cehteh @jameshowell This is 100% on Emacs to fix, because it is Emacs that is unprompted running git on a repository
I agree that git's design here is the problem, but to run an unsafe tool without asking isn't acceptable. Yes that will reduce the usefulness of vc-mode, but so what? A state of "this is inside a git-controlled workarea, and you'll have to do something to get more information" is really the only safe automatic use of git
Philip@tfb @cehteh @jameshowell Git should have a "--safe" flag, or at least a "--read-only" option. Emacs just needs to read some information like the current revision off disk, not modify anything. Prompting users all the time would be a serious annoyance.
That would be a easy solution. Some git repositories won't be readable then (see gitcrypt for example), but i think thats ok and a low hanging fruit. Also with --safe you have the contrary situation that you may not be able to verify commit signatures 😩
@cehteh Once the someone has decided to interact with a git checkout as such, it's probably fine to assume they intend to do so.
The really nasty corner here IMO is that you might not be aware that you're finding a file in a working copy, nor that editing a file from it might involve executing something outside of Emacs
@pkal @cehteh @jameshowell I agree, but git doesn't have such a flag. Maybe Emacs needs its own read-only git implementation, like how it has rcs2log and hexl
@tfb @cehteh @jameshowell I wonder if Emacs could approximate this by always starting Git with --config options that would overwrite exploits of this kind.
That is what Claude suggested as fix, but incomplete. It would be a pretty bad practice to do so because then one has to chase whatever git implements and sanitize it, always leaving a gap for exploits. Furthermore some repositories only work when certain things are enabled. not running git at all when the repository is not trusted (maintaining a list in emacs or git) or having a --safe/--untrusted flag in git would be one solution. There are other possible solutions could be that configs must be signed. I would probably prefer some hybrid approach, having a global .gitdirs with patterns like .gitignore and flags what to do with .git's that match (trust, dont trust, check signature (and add)) etc. but all comes with some drawbacks (performance)