Re: Proposal: server-advertised config options

From: Drew DeVault <sir@cmpwn.com>
Date: Sep 8, 2020, 14:14 UTC
Message-ID: <C5I1TZ1OCN40.2BHKV9GD572FL@homura>
In-Reply-To: <20200907205242.GF241078@camp.crustytoothpaste.net>

On Mon Sep 7, 2020 at 4:52 PM EDT, brian m. carlson wrote:

Show 6 quoted lines

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

Show 5 quoted lines

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

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

Show 5 quoted lines

> It doesn't automatically "just work", but it also lets projects decide
> for themselves what their settings should be. Just because a site
> offers, say, mailing lists, doesn't mean that folks will want to use
> those mailing lists. For example, the Go language repository is hosted
> on GitHub, but uses Gerrit for code review, not GitHub pull requests.

Note that in the case of sourcehut, mailing lists are optional. It's not like GitHub where you can't turn off pull requests and have to deal with rejecting them manually or set up a bot to auto-close them or something.