These are SHA256 TODO leftover.
In the surrounding context they all have the required oid type around,
so I just picked up them and pass in.
Found during SHA256 support integration with Rust git-rs binding
Look for the `GIT_SSH_COMMAND` environment variable and prefer it to
`GIT_SSH`. The `GIT_SSH_COMMAND` will execute via the shell, which is
useful to provide additional arguments.
When sending paths to the remote server, escape them properly.
Escape them with a single quote, followed by the escaped character,
followed by another single quote. This prevents misparsing on the
remote side and potential command injection.
Allow `git_str_puts_escaped` to take an escaping prefix and an escaping
suffix; this allows for more options, including the ability to better
support escaping executed paths.
Construct the arguments for the ssh exec as an explicit array, instead
of trying to create a command-line for sh. The latter may use user input
(the remote path) so this may be vulnerable to command injection.
When using `git_process_new` on win32, resolve the path to the
application in the same way that we do on POSIX.
Search `PATH` for command to execute (unless the given executable is
fully qualified). In addition, better match Windows executable lookup
behavior itself (allowing the command to be `foo`, and looking for a
matching `foo.exe` or `foo.cmd`.)
By default, `git_process_new` will no longer try to prepare a single
string to execute with the shell. Instead, by default, arguments remain
parameterized and the command to execute is located within the `PATH`.
The shell can also still optionally be used (so that additional
arguments can be included and variables handled appropriately) but this
is done by keeping arguments parameterized for safety.
This new behavior prevents accidental misuse and potential command-line
injection.
Ensure that when we look for an executable on Windows that we add
executable suffixes (`.exe`, `.cmd`). Without this, we would not support
looking for (eg) `ssh`, since we actually need to identify a file named
`ssh.exe` (or `ssh.cmd`) in `PATH`.
* Do not search `PATH` for fully- or partially-qualified filenames
(eg, `foo/bar`)
* Ensure that a file in the `PATH` is executable before returning it
Ensure that our `find_executable` behaves as expected:
* When the executable contains a fully- or partially-qualified filename
component (eg, `foo/bar`) that `PATH` is not searched; these paths are
relative to the current working directory.
* An empty segment in `PATH` (on POSIX systems) is treated as the
current directory; this is for compatibility with Bourne shells.
* When a file exists in `PATH`, it is actually executable (on POSIX)
It's certainly possible for the root filesystem to be case-sensitive
while /tmp is not, or vice versa. One example where this might happen
is when running Docker containers (like ci/docker/fedora) on macOS with
the repository checkout on AppleFS (not case sensitive) while the
container's /tmp is case sensitive.
This fix allows the test to pass under those circumstances as well.
GIT_REFERENCE_FORMAT_REFSPEC_SHORTHAND is documented to "interpret the
name as part of a refspec in shorthand form so the ONELEVEL naming rules
aren't enforced and 'master' becomes a valid name."
However, the multi-segment pseudoref check was not respecting this flag,
rejecting valid refspecs like "A/b" and "HEAD/feature" even when
SHORTHAND was set.
The single-segment check at line 1015 already honors this flag. This
change makes the multi-segment check at line 1021 consistent with that
behavior and with the documented intent.
Git itself accepts these refspec patterns without issue.
