Re: Proposal: server-advertised config options

["Drew DeVault" <sir@cmpwn.com>]

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.

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

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