[TOPIC 8/8] Using Git securely in shared services

[Taylor Blau <me@ttaylorr.com>]

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