@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.

@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*

@jameshowell

@tfb @jameshowell

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 @tfb @jameshowell

I think a solution may be this tar argument.

--exclude-vcs Exclude version control system directories.

The problem is if someone slips you an untrusted .git/config it can execute code on your system.

but untrusted .git/ directories can run arbitrary code through a number of other mechanisms as well.

It's probably not a great idea to unpack something without reviewing its contents first.

I'm pretty sure if you git clone, the config file only contains settings you set.