You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The first of two strategies used by the `system_prefix()` function
on Windows is an optimization that looks for `clangarm64`,
`mingw64`, or `mingw32` subdirectories of a directory whose path is
given by the value of the `EXEPATH` environment variable. If
`EXEPATH` is absent, can't be interpreted as a path, or can be
interpreted as a path but does not point to a directory that can be
verified to contain such a subdirectory, then this optimization was
already being skipped and the more reliable but sometimes slower
`git --exec-path`-based method used.
However, when `EXEPATH` contains a relative path, including in the
case where it is an empty string (which could be set by accident or
if it is being used with some meaning other than what we and Git
for Windows recognize), then it was still used, even though that
would not usually be correct and would sometimes not be safe.
Although an attacker is not expected to be able to control the
value of `EXEPATH` (nor most environment variables), a value such
as an empty string would cause `clangarm64`, `mingw64`, and
`mingw32` subdirectories of the current directory to be used.
A user might intentionally set `EXEPATH` to a relative path to
leverage the `EXEPATH` optimization of `system_prefix()` with that
path. But `EXEPATH` is a short variable name with many plausible
meanings that is not named with a distinctive prefix such `GIT_` or
`GIX_`. So it would not be a good tradeoff to continue recognizing
it for `system_prefix()` anytime it is non-absoliute.
Thus, as a stability fix and possible security enhancement, this
adds a check that the value of `EXEPATH` is an absolute path before
proceeding with the `EXEPATH` optimization.
0 commit comments