On Thu, Nov 03, 2016 at 11:45:38AM -0700, Brandon Williams wrote: > On 11/03, Jeff King wrote: > > > > So this seems like a reasonable direction to me. It obviously needs > > documentation and tests. Arguably there should be a fallback "allow" > > value when a protocol is not mentioned in the config so that you could > > convert the default from "user" to "never" if you wanted your config to > > specify a pure whitelist. > > Yes I agree there should probably be a fallback value of 'never' maybe? > What you currently have preserves the behavior of what git does > now, if we did instead have a fallback of 'never' it would break current > users who don't already use GIT_ALLOW_PROTOCOL (well only if they use > crazy protocols). We could ease into it though and start with default > to allow and then transition to a true whitelist sometime after this > change has been made? I don't see the value in moving the out-of-the-box install to any default except "user". Right now the experience of using a third-party helper is something like: cp git-remote-hg /somewhere/in/your/PATH git clone hg::whatever We restrict its use in submodules by default, which is unlikely to bite many people. But if we started falling back to "never" all the time, then that second command would break until you officially "approve" remote-hg in your config. I was thinking of just something to let people decide to have that level of paranoia themselves (especially if they want to just set up a whole-system white list via the config without bothering with environment variables). Like: git config --system protocol.allow never git config --system protocol.https.allow always That behaves exactly like: export GIT_ALLOW_PROTOCOL=https except it just works everywhere, without having to tweak the environment of every process. > > Do you have interest in picking this up and running with it? > > Yep! Thanks for the help in shaping this. Great, thanks. I'm happy to review or discuss further as necessary. -Peff