Re: proposal for additional search path in config

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