181 lines · 9.2 KB · Rust
RawDownload
use std::{    ffi::OsString,    path::{Path, PathBuf},}; use std::sync::LazyLock; /// `usr`-like directory component names that MSYS2 may provide, other than for `/usr` itself.////// These are the values of the "Prefix" column of the "Environments" and "Legacy Environments"/// tables in the [MSYS2 Environments](https://www.msys2.org/docs/environments/) documentation,/// with the leading `/` separator removed, except that this does not list `usr` itself.////// On Windows, we prefer to use `sh` as provided by Git for Windows, when present. To find it, we/// run `git --exec-path` to get a path that is usually `<platform>/libexec/git-core` in the Git/// for Windows installation, where `<platform>` is something like `mingw64`. It is also acceptable/// to find `sh` in an environment not provided by Git for Windows, such as an independent MSYS2/// environment in which a `git` package has been installed. However, in an unusual installation,/// or if the user has set a custom value of `GIT_EXEC_PATH`, the output of `git --exec-path` may/// take a form other than `<platform>/libexec/git-core`, such that finding shell at a location/// like `../../../bin/sh.exe` relative to it should not be attempted. We lower the risk by/// checking that `<platform>` is a plausible value that is not likely to have any other meaning.////// This involves two tradeoffs. First, it may be reasonable to find `sh.exe` in an environment/// that is not MSYS2 at all, for which in principle the prefix could be different. But listing/// more prefixes or matching a broad pattern of platform-like strings might be too broad. So only/// prefixes that have been used in MSYS2 are considered.////// Second, we don't recognize `usr` itself here, even though it is a plausible prefix. In MSYS2,/// it is the prefix for MSYS2 non-native programs, i.e. those that use `msys-2.0.dll`. But unlike/// the `<platform>` names we recognize, `usr` also has an effectively unbounded range of plausible/// meanings on non-Unix systems (for example, what should we take `Z:\usr` to mean?), which might/// occasionally relate to subdirectories with contents controlled by different *user accounts*.////// If we start with a `libexec/git-core` directory that we already use and trust, and it is in a/// directory with a name like `mingw64`, we infer that this `mingw64` directory has the expected/// meaning and accordingly infer that its `usr` sibling, if present, is acceptable to treat as/// though it is a first-level directory inside an MSYS2-like tree. So we are willing to traverse/// down to `usr/sh.exe` and try to use it. But if the `libexec/git-core` we use and trust is in a/// directory named `usr`, that `usr` directory may still not have the meaning we expect of `usr`.////// Conditions for a privilege escalation attack or other serious malfunction seem far-fetched. If/// further research finds the risk is low enough, `usr` may be added. But for now it is omitted.const MSYS_USR_VARIANTS: &[&str] = &["mingw64", "mingw32", "clangarm64", "clang64", "clang32", "ucrt64"]; /// Find a Git for Windows installation directory based on `git --exec-path` output.////// Currently this is used only for finding the path to an `sh.exe` associated with Git. This is/// separate from `installation_config()` and `installation_config_prefix()` in `gix_path::env`./// This is *not* suitable for finding the highest-scoped configuration file, because that could be/// installed in an unusual place, or customized via `GIT_CONFIG_SYSTEM` or `GIT_CONFIG_NOSYSTEM`,/// all of which `installation_config()` should reflect. Likewise, `installation_config_prefix()`/// has strong uses, such as to find a directory inside `ProgramData` containing configuration./// But it is possible that some marginal uses of `installation_config_prefix()`, if they do not/// really relate to configuration, could be replaced with `git_for_windows_root()` in the future.fn git_for_windows_root() -> Option<&'static Path> {    static GIT_ROOT: LazyLock<Option<PathBuf>> = LazyLock::new(|| {        super::core_dir()            .filter(|core| {                // Only use this if the directory structure resembles a Git installation. This                // accepts installations of common types that are not broken when `GIT_EXEC_PATH`                // is unset, as well as values of `GIT_EXEC_PATH` that are likely to be usable.                core.is_absolute() && core.ends_with("libexec/git-core")            })            .and_then(|core| core.ancestors().nth(2))            .filter(|prefix| {                // Only use `libexec/git-core` from inside something `usr`-like, such as `mingw64`.                // See `MSYS_USR_VARIANTS` for details and the rationale for this restriction.                MSYS_USR_VARIANTS.iter().any(|name| prefix.ends_with(name))            })            .and_then(|prefix| prefix.parent())            .map(Into::into)    });    GIT_ROOT.as_deref()} /// `bin` directory paths to try relative to the root of a Git for Windows or MSYS2 installation.////// These are ordered so that a shim is preferred over a non-shim when they are tried in order.const BIN_DIR_FRAGMENTS: &[&str] = &["bin", "usr/bin"]; /// Obtain a path to an executable command on Windows associated with Git, if one can be found.////// The resulting path uses only `/` separators so long as the path obtained from `git --exec-path`/// does, which is the case unless it is overridden by setting `GIT_EXEC_PATH` to an unusual value.////// This is currently only used (and only heavily exercised in tests) for finding `sh.exe`. It may/// be used to find other executables in the future, but may need adjustment. In particular,/// depending on desired semantics, it should possibly also check a `cmd` directory; directories/// like `<platform>/bin`, for any applicable variants (such as `mingw64`); and `super::core_dir()`/// itself, which it could safely check even if its value is not safe for inferring other paths.fn find_git_associated_windows_executable(stem: &str) -> Option<OsString> {    let git_root = git_for_windows_root()?;     BIN_DIR_FRAGMENTS        .iter()        .map(|bin_dir_fragment| {            // Perform explicit raw concatenation with `/` to avoid introducing any `\` separators.            let mut raw_path = OsString::from(git_root);            raw_path.push("/");            raw_path.push(bin_dir_fragment);            raw_path.push("/");            raw_path.push(stem);            raw_path.push(".exe");            raw_path        })        .find(|raw_path| Path::new(raw_path).is_file())} /// Like `find_associated_windows_executable`, but if not found, fall back to a simple filename.pub(super) fn find_git_associated_windows_executable_with_fallback(stem: &str) -> OsString {    find_git_associated_windows_executable(stem).unwrap_or_else(|| {        let mut raw_path = OsString::from(stem);        raw_path.push(".exe");        raw_path    })} #[cfg(test)]mod tests {    use std::path::Path;     /// Some commands with `.exe` files in `bin` and `usr/bin` that should be found.    ///    /// Tests are expected to run with a full Git for Windows installation (not MinGit).    const SHOULD_FIND: &[&str] = &[        "sh", "bash", "dash", "diff", "tar", "less", "sed", "awk", "perl", "cygpath",    ];     /// Shouldn't find anything nonexistent, or only in PATH or in `bin`s we don't mean to search.    ///    /// If dirs like `mingsw64/bin` are added, `git-credential-manager` should be moved to `SHOULD_FIND`.    /// Likewise, if `super::core_dir()` is added, `git-daemon` should be moved to `SHOULD_FIND`.    const SHOULD_NOT_FIND: &[&str] = &[        "nonexistent-command",        "cmd",        "powershell",        "explorer",        "git-credential-manager",        "git-daemon",    ];     #[test]    #[cfg_attr(not(windows), ignore = "only meaningful on Windows")]    fn find_git_associated_windows_executable() {        for stem in SHOULD_FIND {            let path = super::find_git_associated_windows_executable(stem);            assert!(path.is_some(), "should find {stem:?}");        }    }     #[test]    #[cfg_attr(not(windows), ignore = "only meaningful on Windows")]    fn find_git_associated_windows_executable_no_extra() {        for stem in SHOULD_NOT_FIND {            let path = super::find_git_associated_windows_executable(stem);            assert_eq!(path, None, "should not find {stem:?}");        }    }     #[test]    #[cfg_attr(not(windows), ignore = "only meaningful on Windows")]    fn find_git_associated_windows_executable_with_fallback() {        for stem in SHOULD_FIND {            let path = super::find_git_associated_windows_executable_with_fallback(stem);            assert!(Path::new(&path).is_absolute(), "should find {stem:?}");        }    }     #[test]    #[cfg_attr(not(windows), ignore = "only meaningful on Windows")]    fn find_git_associated_windows_executable_with_fallback_falls_back() {        for stem in SHOULD_NOT_FIND {            let path = super::find_git_associated_windows_executable_with_fallback(stem)                .to_str()                .expect("valid Unicode")                .to_owned();            assert_eq!(path, format!("{stem}.exe"), "should fall back for {stem:?}");        }    }}