On 2020-09-08 at 14:14:47, Drew DeVault wrote:
> On Mon Sep 7, 2020 at 4:52 PM EDT, brian m. carlson wrote:
> > The Git security model doesn't permit untrusted config options, so I
> > think it's risky to add support for config options from the server
> > side. We need to consider not only advanced users who are going to be
> > able to make a good decision here, but novice users who are struggling
> > to understand how Git works and are prone to social engineering. Just
> > because your server is not malicious does not mean that others aren't.
> 
> Hm. If we view some of these use-cases as legitimate, maybe it would
> make sense to only permit a hard-coded list of config options to be
> advertised, removing all other configurability to avoid letting users
> configure themselves into a compromised system (potentially via social
> engineering). For example, project policies like sendmail.to and config
> options in the server's domain like push options would be in-scope, but
> something like core.editor would be out of scope.

sendmail.to would potentially leak information if you cloned a
repository from one server but intended to use it internally to send
patches elsewhere, especially if you'd already set that option globally.
I'm pretty sure that other scenarios exist where even mundane config
options can be leveraged as an attack vector.

That's the problem: we as the defenders have to come up with every
possible scenario to allow a trusted config item, and an attacker just
has to come up with one scenario to exploit it.  We've seen security
problems in the past with .gitmodules multiple times because it's
server-sent config (in the repository).  Vim has also seen multiple CVEs
from untrusted configuration (modelines).  It's just a minefield waiting
to happen.

As a result, I'm very much opposed to allowing any config options to be
copied from the server.

> > In addition, if I'm cloning a repository just to build it, I don't want
> > to be prompted to set those configuration options at all. My experience
> > in Git hosting is that clones and fetches far, far outnumber pushes, so
> > adding a prompting feature adds a bunch of impediment with little gain
> > for the vast majority of users.
> 
> That alternative approach would also eliminate the need for prompting.

Are you suggesting that we just accept the server's settings without
prompting?  I certainly don't think that's a viable approach.

> > That doesn't mean you can't provide a downloadable shell script that
> > people could check into their repositories to configure this for the
> > user.
> 
> Yeah, but that also eliminates most of the convenience factor and is
> even more of a risk.

It's also the standard approach that every project uses already, and it
has the benefit that the user can inspect it at their leisure before
running it.
-- 
brian m. carlson: Houston, Texas, US