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
Attachment:
signature.asc
Description: PGP signature
