The risks of embedded bare repositories in Git

Posted Apr 28, 2022 2:46 UTC (Thu) by pabs (subscriber, #43278)
Parent article: The risks of embedded bare repositories in Git

I feel like the right solution is to have a list of trustworthy repositories configured in your global git config and only allow running commands from them.

The risks of embedded bare repositories in Git

Posted Apr 28, 2022 9:27 UTC (Thu) by MrWim (subscriber, #47432) [Link] (2 responses)

Or a central list of hooks that are deemed "safe" that could run in any git repo. A malicious git repo might not be embedded inside another one afterall. It might come embedded inside a hg repo or tarball. Just because it's on your filesystem doesn't mean it can be trusted.

Generally speaking actions that feel safe should be made safe. Extracting a tarball, cloning a git repo, `cd`ing to a directory, `cat`ing a file all feel rather pedestrian - and if there are subtle security issues with them it's the software that needs to be fixed.

The risks of embedded bare repositories in Git

Posted Apr 28, 2022 10:04 UTC (Thu) by geert (subscriber, #98403) [Link] (1 responses)

The git repository might be inside a tarball.

The risks of embedded bare repositories in Git

Posted Apr 28, 2022 12:20 UTC (Thu) by MrWim (subscriber, #47432) [Link]

Exactly, that's what I meant by:

> It might come embedded inside a [...] tarball.

The risks of embedded bare repositories in Git

Posted Apr 28, 2022 11:13 UTC (Thu) by k3ninho (subscriber, #50375) [Link] (4 responses)

>I feel like the right solution is to have a list of trustworthy repositories configured in your global git config and only allow running commands from them.
Sure, give me the web address of the shell script to update the whitelist and I'll curl-pipe-sudo-bash it right away.

Oops.

K3n.

The risks of embedded bare repositories in Git

Posted Apr 28, 2022 14:19 UTC (Thu) by MrWim (subscriber, #47432) [Link] (3 responses)

I believe the suggestion was that you have a *local* list of repositories on your computer that *you* trust. It could be `~/.gittrusted` for example. It might look like:

Projects/linux
Projects/foo
Projects/bar

So then when you run `git status` in Projects/linux the hooks will be run, while if you run it in ~/Downloads/my-dodgy-project no hooks will be run.

The risks of embedded bare repositories in Git

Posted Apr 28, 2022 14:47 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

For prior art along these lines, see myrepos' `.mrtrust` file. https://myrepos.branchable.com/

The risks of embedded bare repositories in Git

Posted Apr 29, 2022 2:25 UTC (Fri) by pabs (subscriber, #43278) [Link]

Yep, that is where the idea came from; I'm one of the upstream maintainers of myrepos, and use it regularly, although not the mrtrust feature.

The risks of embedded bare repositories in Git

Posted Apr 29, 2022 2:24 UTC (Fri) by pabs (subscriber, #43278) [Link]

Right, although that doesn't solve the issue that k3ninho mentions; running arbitrary unreviewed code (which developers do a lot) could update the list of trusted directories. You would need to use bubblewrap or another container solution to prevent random code from touching the list of trusted dirs.