Byron/gitoxide gix-path-v0.10.11

gix-path v0.10.11

on GitHub

Bug Fixes

• Don't require usable temp dir to get installation config
  When running git config -l ... to find the configuration file
  path associated with the git installation itself, the current
  working directory for the subprocess was set to the current
  directory prior to #1523, and to /tmp or a /tmp-like directory
  since #1523 (which improved performance and security).

  This builds on #1523, as well as on subsequent changes to run git
  in a way that its behavior depends less on its CWD, by making an
  even more robust choice of CWD for the subprocess, so that the CWD
  is less likely to be deeply nested or on network storage; more
  likely to exist; and, on Unix-like systems, less likely to contain
  a .git entry (though a git with security updates should refuse
  to take any configuration from such a repository unless it is owned
  by the user).

  Due to a combination of other measures that harden against
  malicious or unusual contents (especially setting GIT_DIR), the
  most significant benefit of this change is to fix the problem that
  a nonexistent temp dir would prevent the command from succeeding.

  The main way that could happen is if TMPDIR on Unix-like systems,
  or TMP or TEMP on Windows, is set to an incorrect value.
  Because these variables are sometimes reasonable to customize for
  specific purposes, it is plausible for them to be set to incorrect
  values by accident.

  Except on Windows, this always uses / as the CWD for the
  subprocess.

  On Windows, we use the Windows directory (usually C:\Windows)
  rather than the root of the system drive (usually C:\), because:

  • We are currently obtaining this information from environment
    variables, and it is possible for our own parent process to pass
    down an overly sanitized environment.

  Although this can be so sanitized we cannot find the Windows
  directory, this is less likely to occur than being unable to find
  the root of the system drive.

  This due to moderately broad awareness that the SystemRoot
  environment variable (which, somewhat confusingly, holds the path
  of the Windows directory, not the root of the system drive)
  should be preserved even when clearing most other variables.

  Some libraries will even automatically preserve SystemRoot when
  clearing others or restore it. For example:

  • https://go-review.googlesource.com/c/go/+/174318

• Under the current behavior of env::temp_dir(), which is now a
  fallback if we cannot determine the Windows directory, we already
  fall back to the Windows directory evenutally, if temp dir
  related environment variables are also unset.

  This is because env::temp_dir() usually calls GetTempDir2 in
  the Windows API, which implements that fallback behavior (after
  first trying the user's user profile directory).

  Avoiding adding yet another place to fall back to that would not
  otherwise be attempted slightly decreases behavioral complexity,
  and there is no reason to think a directory like C:\ would work
  when a directory like C:\Windows doesn't.

• The root of the system drive on a Windows system usually permits
  limited user accounts to create new directories there, so a
  directory like C:\ on Windows actually has most of the
  disadvantages of a location like /tmp on a Unix-like system.

  • GHSA-vw2c-22j4-2fh2
  • GHSA-mgvv-9p9g-3jv4

  This is actually a much less significant reason to prefer a
  directory like C:\Windows to a directory like C:\ than it
  might seem. After all, if C:\.git exists and and git uses it
  when run from C:\, then git would usually also use it when
  run from C:\Windows (and from numerous other locations)!

  However, the reason there is still a small reason to prefer a
  location like C:\Windows to a location like C:\ is that, if a
  system has a vulnerable git but a user or system administrator
  has sought to work around it by listing C:\ in
  GIT_CEILING_DIRECTORIES, then that may keep git from
  traversing upward into C:\, but it would not keep C:\ from
  being used if that is where we already are.

  An even more significant reason this motivation is a minor one is
  that the other measures we are taking, including setting
  GIT_DIR, should be sufficient to avoid at least the security
  dimension of the problem, which arises from actually using the
  configuration from a repo that is discovered.

• GHSA-mgvv-9p9g-3jv4

• The user profile directory may be more deeply nested.

• The user profile directory may sometimes be on slow network
  storage when the discovered Windows directory is not.

• In some situations, the user profile directory does not actually
  exist, or does not exist yet.

• Overly sanitized environments are more likely to lack the
  USERPROFILE vairable than the SystemRoot variable.

• Users may occasionally choose to have their entire user profile
  directory be a Git repository.

• It's no easier to avoid the problem of using C:\.git in a user
  profile directory than in C:\Windows: they're usually both under
  C:\, and are both not the same as C:\. (If the user profile
  directory is a repository, then that will avoid that problem, yet
  be its own problem, if not for other measures that prevent both.)

• If the git command is an old and unpatched vulnerable version
  in which safe.directory is not yet implemented, or in which
  GHSA-j342-m5hw-rr3v
  or other vulnerabilities where git would perform operations on
  untrusted local repositories owned by other users are unpatched,
  then a .git subdirectory of a shared /tmp or /tmp-like
  directory could be created by another account, and its local
  configuration would still have been used. (This is not a bug in
  gitoxide per se; having vulnerable software installed that other
  software may use is inherently insecure. But it is nice to offer
  a small amount of protection against this when readily feasible.)

• If the /tmp-like location is a Git repository owned by the
  current user, then its local configuration would have been used.

• dotnet/docs#41193

• python/cpython#95486 (comment)

• python/cpython#95486 (comment)

• Parsing is more reliable for paths containing unusual characters,
  because -z/--null causes all paths to be output literally.

  Previously, " characters were trimmed from the ends, but this
  would not always extract a correct path, because when a path
  contains characters that cause git to enclose it in double
  quotes, those characters are usually represented in a symbolic
  form, usually with \ escapes.

  In some scenarios, such as usually on Windows when the escaped
  character is itself a \ and not in the leading position, the
  mangled path would be usable, but more often it would not.

• The volume of output is less, because --name-only casues values
  not to be included in the output.

• The combination of -z/--null and --name-only makes the
  output format simpler, and the parsing logic is accordingly
  simpler.

Commit Statistics

• 56 commits contributed to the release.
• 14 days passed between releases.
• 3 commits were understood as conventional.
• 0 issues like '(#ID)' were seen in commit messages

Commit Details