Theseconfig_args passing command-scope Git configuration variables via-c are only meaningful if the executable being run isgit or otherwise recognizesgit options. But thisGit.execute method is not limited to runninggit. It is intentionally usable to run any command in an environment that theGit object would rungit in, in a manner similar to how it would rungit.

Even if I am right to think, as expressed in#2029 (comment), that "safe mode" need not inherently preclude other subprocess invocations from occurring so long as they are not happening throughgit, it seems to me that users may intuitively assume that the protections apply to all use ofexecute when "safe mode" is enabled and not overridden in any way. It also seems like that is part of the intent here.

Furthermore, sinceexecute uses state associated with the repository--itscwd in particular--I think the risks "safe mode" is meant to mitigate can only be mitigated if its protections apply to allexecute calls for which "safe mode" is considered to be in effect. And ifexecute is used to run something that itself runsgit, such as a script ofgit commands, then it could be a problem for the necessary command-scope configuration not to be in effect.

It seems to me that a simple and effective solution to the problem thatgit options could be passed to programs other thangit is therefore for "safe mode" to enforce, not merely thatcommand is the right kind of object (see above), but also that its first element is exactly what it would be whenexecute is called through_call_process--that is, that the first element is equal toGit.GIT_PYTHON_GIT_EXECUTABLE.

If for some reason it is necessary in "safe mode" forexecute to run other programs besides thegit executable that_call_process would use, then it might be possible to pass the command-scope configuration entirely using environment variables, either always or in the case that the command is notGit.GIT_PYTHON_GIT_EXECUTABLE.

However, I think this would be challenging, both in general because of the increased complexity it would entail, and more specifically because, of the two ways to pass command-scope Git configuration variables using environment variables:

• GIT_CONFIG_{COUNT,KEY,VALUE} is not recognized by all versions ofgit in current use (some distributions maintain old versions with downstream security patches but not new features).
• GIT_CONFIG_PARAMETERS is considered an implementation detail ofgit with two different syntaxes so fardepending on thegit version.

It seems to me that a simple and effective solution to the problem that git options could be passed to programs other than git is therefore for "safe mode" to enforce, not merely that command is the right kind of object (see above), but also that its first element is exactly what it would be when execute is called through _call_process--that is, that the first element is equal to Git.GIT_PYTHON_GIT_EXECUTABLE.

Thanks for this detailed analysis! I agree with this approach. I'll try implementing it. I was not aware that GitPython is executing other things besidesgit. Makes sense to me that safe mode should also restrict those as well.

I think without exhaustive tests and actually challenging the code we wouldn't want to make the flag seem like a perfect defence.
Somehow I feel thatas safe as possible should rather be a disclaimer about this being a best-effort basis and that the defence is probably not complete, while stating what it focusses on.

Agreed. This is what I have so far:

Lock down the configuration to make it as safe as possible when working with publicly accessible, untrusted repositories. This disables all known options that can run an external program and limits networking to the HTTP protocol via https:// URLs. This might not cover Git config options that were added since this was implemented, or options that might have unknown exploit vectors. It is a best effort defense rather than an exhaustive protection measure.

That sounds good! Maybe it makes sense to explicitly mention configuration keys with subsections, as these are particularly hard to pickup.

On the bright side, thinking about it, this would only be a problem if someone else controls the environment or the configuration. Maybe the latter is common for repositories on shared drives?