fix: Extend ALTERNATIVE_LOCATIONS for ARM64 Windows

`gix-path` looks for and runs an installed `git` executable, when
present, to discover information about how Git is set up. This
is used in several functions in `gix_path::env`, especially on
Windows, where if `git.exe` is not found in a `PATH` search, then
common installation locations for Git for Windows are checked.

These locations on Windows are resolved based on information from
the current environment, since different systems have different
program files directories. This was implemented in GitoxideLabs#1456 (which
built on GitoxideLabs#1419). Although this was sufficient to find the most
common Git for Windows installation locations, it did not find
ARM64 builds of Git for Windows. Such builds place the non-shim
`git.exe` program in `(git root)\clangarm64\bin`, rather than in
`(git root)\mingw64\bin` or `(git root)\mingw32\bin`. At the time
of GitoxideLabs#1419 and GitoxideLabs#1456, no stable ARM64 builds of Git for Windows were
available. Since then, Git for Windows began releasing such builds.

This modifies the alternative locations examined if `git.exe` is
not found in a `PATH` search on Windows so that, where `(git root)`
is in a 64-bit program files directory, we check for a
`(git root)\clangarm64\bin` directory, in addition to checking for
a `(git root)\mingw64\bin` directory as was already done.

Although 64-bit and 32-bit program files directories are separate,
on ARM64 systems the 64-bit program files directory is used both
for ARM64 programs, which the system can run directly, and for
x86_64 programs, which the system must run through emulation.

This checks both `clangarm64` and `mingw64`, where `mingw64` was
checked before. It does so in that order, because if both are
available, then we are probably on an ARM64 system, and the ARM64
build of Git for Windows should be preferred, both because it will
tend to perform better and because the user is likely to expect
that to be used. (An x86_64 build, especially if present directly
alongside an ARM64 build, may be left over from a previous version
of Git for Windows that didn't have ARM64 builds and that was only
incompletely uninstalled.)

This checks both, in that order, on all systems where we had
checked `mingw64` before, even on x86_64 systems. This is because:

- To limit production dependencies and code complexity, we have
  been examining only environment variables (and information
  available at build time) to ascertain which program files
  directories exist and whether they are 64-bit or 32-bit program
  files directories. At least for now, this preserves that general
  approach, continuing not to explicitly call Windows API functions
  or access the Windows registry, other than in tests.

- But determining from environment variables whether the system is
  ARM64 or x86_64 is less straightforward than determining the
  program files directory locations, in one major case as well as
  various edge cases.

The reason it's less straightforward is that, if our parent process
(or other ancestor) passes down a sanitized environment while still
attempting to let the program files directories be found, then:

- That process should make available all of the `ProgramFiles`,
  `ProgramW6432`, `ProgramFiles(x86)`, and `ProgramFiles(ARM)`
  variables that exist in its own environment.

  (This is because, on 64-bit Windows, the child `ProgramFiles` is
  populated from the parent `ProgramW6432`, `ProgramFiles(x86)`, or
  `ProgramFiles(ARM)`, depending on the architectures of the parent
  and child, if the parent passes down the relevant variable.)

- Even if the parent/ancestor is not designed with the WoW64 rules
  in mind, it will likely pass down at least `ProgramFiles`.

  This will then be used as the child `ProgramFiles`, if whichever
  of `ProgramFilesW6432`, `ProgramFiles(x86)`, or
  `ProgramFiles(ARM)` is relevant is not passed down by the parent.

- In contrast, the parent/ancestor may omit the variables
  `PROCESSOR_ARCHITECTURE` and `PROCESSOR_ARCHITEW6432`, which are
  not obviously needed for locating programs.

  In and of itself, this is not necessarily a problem, because on
  ARM64 Windows, at least one of the two will still be set
  automatically. (Even if the parent process runs us with an
  explicitly empty environment, we will get one of these, on ARM64
  Windows.)

  However, in this case, as in others, it will generally be set
  according to our process architecture, rather than the system
  architecture.

- Thus, even if `PROCESSOR_ARCHITE*` variables are preserved or set
  correctly, there are common cases where they are not sufficient.

  The main such case is when we are an x86_64 build, but the system
  is ARM64, and Git for Windows is ARM64. `gix-path` is a library
  crate, and it will sometimes to be used in an x86_64 program on
  such a system.

  Also, if `gix-path` is used in an Arm64EC program, then even
  though its code may be ARM64 with the `arm64ec-pc-windows-msvc`
  Rust target, the program would still be treated as an x86_64
  program in its interactions with the system and other programs,
  including in how its environment variables' values are populated
  and how their values are affected by WoW64.

  (`gix-path` may also be x86_64 code where the program is Arm64EC.
  One way this happens is if `gix-path` is used in an x86_64 DLL,
  and an Arm64EC program loads the DLL. Using x86_64 DLLs from
  ARM64 code is one of the reasons a program may target Arm64EC.
  In this case, the Rust target will be for x86_64, not ARM64 or
  Arm64EC. So checking our own Rust build target can't fully check
  if the program is Arm64EC.)

- Although the `PROCESSOR_IDENTIFIER` variable is more reliable if
  present--see actions/partner-runner-images#117 for an example of
  where this is more reliable than `PROCESSOR_ARCHITECTURE`--it is
  slightly more complex to parse. Much more importantly, unlike
  `PROCESSOR_ARCHITE*`, the `PROCESSOR_IDENTIFIER` variable is not
  set automatically in a child process whose parent/ancestor has
  removed it. Whether or not a parent/ancestor passes down
  `PROCESSOR_ARCHITE*` variables, it may still not choose to let
  `PROCESSOR_IDENTIFIER` through, if it sanitizes the environment.

- It would sometimes work to look for `ProgramFiles(ARM)`. This
  environment variable, if present, gives the 32-bit ARM program
  files directory location on an ARM64 Windows system. If set, then
  the Windows system could be treated as ARM64. However, a
  parent/ancestor process may omit this even when passing down
  program files related environment variables, including
  `ProgramFiles(x86)`. It may do so because the `ProgramFiles(ARM)`
  environment variable is less well known. Or it may omit it
  intentionally, if the parent process is only passing down
  variables needed to find Git for Windows, for which one shouldn't
  need to know the 32-bit ARM program files directory location,
  since Git for Windows has never had 32-bit ARM builds.

  Relatedly, augmenting the search by checking the filesystem for a
  sibling (or hard-coded) directory named `Program Files (ARM)`
  should not be done, because this directory has no special meaning
  outside of ARM64 Windows. It may therefore be left over from a
  previous installation or migration, or even created by a local
  user as in the CVE-2024-40644 scenario patched in GitoxideLabs#1456.

(These complexities all relate to deciding whether and in what
order to search `bin` subdirectories of `clangarm64`, `mingw64`,
and `mingw32`. They would go away if we looked for the shim rather
than the non-shim executable. This is because the path from
`(git root)` to the shim does not contain a directory component
named after a build target. That simplification would carry its own
tradeoffs, and it is unclear if it ought to be done; it is not done
here.)

Author: EliahKagan

gix-path/src/env/git/mod.rs

@@ -38,38 +38,42 @@ where
     // known. So the situation where a process only passes down `ProgramFiles` sometimes happens.
     let varname_current = "ProgramFiles";
 
-    // 64-bit relative bin dir. So far, this is always `mingw64`, not `ucrt64`, `clang64`, or `clangarm64`.
-    let suffix_64 = Path::new(r"Git\mingw64\bin");
+    // 64-bit relative bin dirs. So far, this is always `mingw64` or `clangarm64`, not `urct64` or
+    // `clang64`. We check `clangarm64` before `mingw64`, because in the strage case that both are
+    // available, we don't want to skip over a native ARM64 executable for an emulated x86_64 one.
+    let suffixes_64 = [r"Git\clangarm64\bin", r"Git\mingw64\bin"].as_slice();
 
-    // 32-bit relative bin dir. So far, this is always `mingw32`, not `clang32`.
-    let suffix_32 = Path::new(r"Git\mingw32\bin");
+    // 32-bit relative bin dirs. So far, this is only ever `mingw32`, not `clang32`.
+    let suffixes_32 = [r"Git\mingw32\bin"].as_slice();
 
     // Whichever of the 64-bit or 32-bit relative bin better matches this process's architecture.
     // Unlike the system architecture, the process architecture is always known at compile time.
     #[cfg(target_pointer_width = "64")]
-    let suffix_current = suffix_64;
+    let suffixes_current = suffixes_64;
     #[cfg(target_pointer_width = "32")]
-    let suffix_current = suffix_32;
+    let suffixes_current = suffixes_32;
 
     let rules = [
-        (varname_64bit, suffix_64),
-        (varname_x86, suffix_32),
-        (varname_current, suffix_current),
+        (varname_64bit, suffixes_64),
+        (varname_x86, suffixes_32),
+        (varname_current, suffixes_current),
     ];
 
     let mut locations = vec![];
 
-    for (name, suffix) in rules {
+    for (name, suffixes) in rules {
         let Some(pf) = var_os_func(name) else { continue };
         let pf = Path::new(&pf);
         if pf.is_relative() {
             // This shouldn't happen, but if it does then don't use the path. This is mainly in
             // case we are accidentally invoked with the environment variable set but empty.
             continue;
         }
-        let location = pf.join(suffix);
-        if !locations.contains(&location) {
-            locations.push(location);
+        for suffix in suffixes {
+            let location = pf.join(suffix);
+            if !locations.contains(&location) {
+                locations.push(location);
+            }
         }
     }