Since git_oid_raw_cmp uses memcmp, it's far easier to optimise more aggressively.
Given that it's static const and used inlined, it seems reasonable to assume that git_oid_zero will be optimised away in release.
This is at least the case with x86-64 and GCC 15.2.1.
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
The expression (c & 0x7f) << shift in hdr_sz() causes undefined
behavior when shift >= 32, because (c & 0x7f) is an unsigned int
(32-bit type). A malicious delta with a long varint can trigger this.
Fix by:
1. Casting to size_t before shifting to support 64-bit shifts
2. Adding a shift limit check to reject overlong varints
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`.
