How to run git securely in shared services (Kevin) - Kevin: What do we think about GIt on a shared device? e.g. Git trusts the repo more than the global config, but the repo might not be trustable. What do we think of, say, inverting this precedence? - bmc: Repo config overriding global config is an important feature we should not lose. But I could imagine some global option that affects that behavior — making it very explicit, on that particular machine. - Stolee: I wrote an email to the mailing list months ago about this subject. Title "What is Git's security boundary?" Concrete proposal: anything that executes an executable could go through a hook that is installed at the global or system level, and local config can refer to that. E.g. "please run vim, which has been controlled at the system level". - I got zero traction, but there's some prior art. - Taylor: We think of Git as special in this way. For "make", we wouldn't ask this same question. - Jrnieder: With "make", it's very clear to users that arbitrary commands might be run, but users don't have that same expectation when just browsing code. - Taylor: We could create a mode that ignores repo config, and that makes prompts safer. But we're inherently make-like. - Jrnieder: That's obvious to us, but not to most users. I think we're quite far from having Git's security model match users' mental model and I think it's hard to change the behavior but would be even harder to change users' mental model in this example. - Jrnieder. I wish we could separate out "repo properties" from "actual config": keep my user preferences separate from the things that Git needs to run. - Ævar: Emacs has solved this. Emacs can run arbitrary code for all kinds of things, but it prompts users to approve the code first. We could allowlist harmless config, and then only prompt users for sketchy things. Taylor: This kind of allowlisting sounds impossible though. Bmc: Can we do this just for core.repositoryformat and extensions.-? - (much spirited discussion, did not hear) - JTan: If we want repositories to still be movable, how would we maintain this allowlist? - Ævar: There are ways to do this for just certain variables, or certain variables in certain paths, etc. We have a lot of space to do the right thing. - Bmc: It's important to make this behavior configurable from the command line. - Ævar: I was experimenting with this because I wanted a way to have config in-repo. It would be very useful even if we could only control a subset of config - Jrnieder: We already have some defense against hooks-and-config in special cases e.g. uploadpack doesn't trust the local repo's hooks. Suppose we have completely solved the problem of protecting against those; are we comfortable with changing the threat model to encompass normal commands in local repositories? - Peff: I think the safest option is to just ignore the in-repo config altogether. Johannes: But the unsafe thing isn't parsing the repo, it's executing code. We could just shift the boundary to "don't execute code outside of safe.directory".
