Hi Jordi, On Tue, 1 Jun 2021, Jordi Vilar wrote: > I would like to gather feedback about a feature I'm considering about. > Basically, I would like to propose a configuration setting with a path > (possibly relative to the working tree) to look for executables. In > that way, a local clone could setup additional tools/scripts private > for its work tree, maybe also under revision control. That sounds like a Remote Code Execution vulnerability by design in the making. But let's read on. > For instance, we could have a setting like: > git config core.extensions_path "./scripts" > so that whenever git has to resolve an external command also includes > that path in the search, resolving relative paths to the work tree, in > this case, the "/scripts" subdir. > > A simple use case could be a custom tool integrated with git, but > local to the repository and thus versioned. > > For instance, let's assume that we have some metadata required by a > custom build tool that is stored in commit comments or tags, so we > have a custom script git-project-metadata to handle it: > git project-metadata query ... > > Maybe the format for the metadata evolves, so the script must evolve > also. Having it integrated in this way would allow that each checkout > sees the correct script version, and that script is always invoked as > a regular git command, without having to tweak the environment > everytime. > > It is not clear to me whether it's a good idea for this additional > path to have priority over the default search path, as in one hand it > could allow to override the default tools, but in the other hand this > may be a hole for bad things... For my, the conservative approach of > having this additional path as a fallback is ok, so that it only adds > more commands, but doesn't override commands. > > Also, this setting could be set either globally or locally, and in > this case, in the conservative approach, the overloading rule is the > different to the normal one: the system search path in the environment > path variable has precedence over the global setting and this over the > local setting, but all apply. > > Does it sound reasonable? Is there interest in such feature? I am really wary about the security implications of this. Most obviously with the idea of allowing to _override_ commands. Take for example `git-lfs`: the assumption is that it is safe for Git to call `git-lfs` after the initial check-out phase, but with this feature, it would be possible for Git to clone a malicious repository and _immediately_ executing code it just cloned, _without_ giving the user a chance to even inspect the code. But even if you _append_ that path to the `PATH` variable, unintended vulnerabilities could be opened. Take for example `git difftool`, which looks for executables in the path until it finds one that is installed. An attacker could guess which executables your setup is missing, and squat on those, overriding your `git difftool` to execute code you did not intend to be executed. So putting a security lens before my eyes, I would be quite worried about such a feature. Note that the _use case_ you present is a common one, and what I see projects do is to integrate the configuration into their build process (carefully vetting any code changes to the build process is _always_ a good idea, hence this is a lot safer than having Git configure what is run automatically). And of course, this is already possible right now, it just delays configuration of those included tools to the time of the first build, as opposed to the clone time (as suggested above). Ciao, Johannes
