Skip to main content

Browse the archive

https://github.com/git/git
17 August 2024, 03:29:52 UTC
sort by:
Revision Author Date Message Commit Date
ecf9b4a Taylor Blau 30 September 2022, 20:56:02 UTC Git 2.31.5 Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 21:39:26 UTC
1225129 Taylor Blau 06 October 2022, 21:39:15 UTC Sync with 2.30.6 Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 21:39:15 UTC
abd4d67 Taylor Blau 30 September 2022, 20:32:10 UTC Git 2.30.6 Signed-off-by: Taylor Blau <me@ttaylorr.com> 06 October 2022, 21:38:16 UTC
0ca6ead Kevin Backhouse 28 September 2022, 22:53:32 UTC alias.c: reject too-long cmdline strings in split_cmdline() This function improperly uses an int to represent the number of entries in the resulting argument array. This allows a malicious actor to intentionally overflow the return value, leading to arbitrary heap writes. Because the resulting argv array is typically passed to execv(), it may be possible to leverage this attack to gain remote code execution on a victim machine. This was almost certainly the case for certain configurations of git-shell until the previous commit limited the size of input it would accept. Other calls to split_cmdline() are typically limited by the size of argv the OS is willing to hand us, so are similarly protected. So this is not strictly fixing a known vulnerability, but is a hardening of the function that is worth doing to protect against possible unknown vulnerabilities. One approach to fixing this would be modifying the signature of `split_cmdline()` to look something like: int split_cmdline(char *cmdline, const char ***argv, size_t *argc); Where the return value of `split_cmdline()` is negative for errors, and zero otherwise. If non-NULL, the `*argc` pointer is modified to contain the size of the `**argv` array. But this implies an absurdly large `argv` array, which more than likely larger than the system's argument limit. So even if split_cmdline() allowed this, it would fail immediately afterwards when we called execv(). So instead of converting all of `split_cmdline()`'s callers to work with `size_t` types in this patch, instead pursue the minimal fix here to prevent ever returning an array with more than INT_MAX entries in it. Signed-off-by: Kevin Backhouse <kevinbackhouse@github.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
71ad7fe Jeff King 28 September 2022, 22:52:48 UTC shell: limit size of interactive commands When git-shell is run in interactive mode (which must be enabled by creating $HOME/git-shell-commands), it reads commands from stdin, one per line, and executes them. We read the commands with git_read_line_interactively(), which uses a strbuf under the hood. That means we'll accept an input of arbitrary size (limited only by how much heap we can allocate). That creates two problems: - the rest of the code is not prepared to handle large inputs. The most serious issue here is that split_cmdline() uses "int" for most of its types, which can lead to integer overflow and out-of-bounds array reads and writes. But even with that fixed, we assume that we can feed the command name to snprintf() (via xstrfmt()), which is stuck for historical reasons using "int", and causes it to fail (and even trigger a BUG() call). - since the point of git-shell is to take input from untrusted or semi-trusted clients, it's a mild denial-of-service. We'll allocate as many bytes as the client sends us (actually twice as many, since we immediately duplicate the buffer). We can fix both by just limiting the amount of per-command input we're willing to receive. We should also fix split_cmdline(), of course, which is an accident waiting to happen, but that can come on top. Most calls to split_cmdline(), including the other one in git-shell, are OK because they are reading from an OS-provided argv, which is limited in practice. This patch should eliminate the immediate vulnerabilities. I picked 4MB as an arbitrary limit. It's big enough that nobody should ever run into it in practice (since the point is to run the commands via exec, we're subject to OS limits which are typically much lower). But it's small enough that allocating it isn't that big a deal. The code is mostly just swapping out fgets() for the strbuf call, but we have to add a few niceties like flushing and trimming line endings. We could simplify things further by putting the buffer on the stack, but 4MB is probably a bit much there. Note that we'll _always_ allocate 4MB, which for normal, non-malicious requests is more than we would before this patch. But on the other hand, other git programs are happy to use 96MB for a delta cache. And since we'd never touch most of those pages, on a lazy-allocating OS like Linux they won't even get allocated to actual RAM. The ideal would be a version of strbuf_getline() that accepted a maximum value. But for a minimal vulnerability fix, let's keep things localized and simple. We can always refactor further on top. The included test fails in an obvious way with ASan or UBSan (which notice the integer overflow and out-of-bounds reads). Without them, it fails in a less obvious way: we may segfault, or we may try to xstrfmt() a long string, leading to a BUG(). Either way, it fails reliably before this patch, and passes with it. Note that we don't need an EXPENSIVE prereq on it. It does take 10-15s to fail before this patch, but with the new limit, we fail almost immediately (and the perl process generating 2GB of data exits via SIGPIPE). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
32696a4 Jeff King 28 September 2022, 22:50:36 UTC shell: add basic tests We have no tests of even basic functionality of git-shell. Let's add a couple of obvious ones. This will serve as a framework for adding tests for new things we fix, as well as making sure we don't screw anything up too badly while doing so. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
a1d4f67 Taylor Blau 29 July 2022, 19:22:13 UTC transport: make `protocol.file.allow` be "user" by default An earlier patch discussed and fixed a scenario where Git could be used as a vector to exfiltrate sensitive data through a Docker container when a potential victim clones a suspicious repository with local submodules that contain symlinks. That security hole has since been plugged, but a similar one still exists. Instead of convincing a would-be victim to clone an embedded submodule via the "file" protocol, an attacker could convince an individual to clone a repository that has a submodule pointing to a valid path on the victim's filesystem. For example, if an individual (with username "foo") has their home directory ("/home/foo") stored as a Git repository, then an attacker could exfiltrate data by convincing a victim to clone a malicious repository containing a submodule pointing at "/home/foo/.git" with `--recurse-submodules`. Doing so would expose any sensitive contents in stored in "/home/foo" tracked in Git. For systems (such as Docker) that consider everything outside of the immediate top-level working directory containing a Dockerfile as inaccessible to the container (with the exception of volume mounts, and so on), this is a violation of trust by exposing unexpected contents in the working copy. To mitigate the likelihood of this kind of attack, adjust the "file://" protocol's default policy to be "user" to prevent commands that execute without user input (including recursive submodule initialization) from taking place by default. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
f4a32a5 Taylor Blau 29 July 2022, 19:21:53 UTC t/t9NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that interact with submodules a handful of times use `test_config_global`. Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
0d3beb7 Taylor Blau 29 July 2022, 19:21:40 UTC t/t7NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Tests that interact with submodules a handful of times use `test_config_global` instead. Test scripts that rely on submodules throughout use a `git config --global` during a setup test towards the beginning of the script. Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
0f21b8f Taylor Blau 29 July 2022, 19:21:18 UTC t/t6NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
225d2d5 Taylor Blau 29 July 2022, 19:21:06 UTC t/t5NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Tests that interact with submodules a handful of times use `test_config_global` instead. Test scripts that rely on submodules throughout use a `git config --global` during a setup test towards the beginning of the script. Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
ac7e57f Taylor Blau 29 July 2022, 19:20:43 UTC t/t4NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Tests that interact with submodules a handful of times use `test_config_global` instead. Test scripts that rely on submodules throughout use a `git config --global` during a setup test towards the beginning of the script. Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
f8d510e Taylor Blau 29 July 2022, 19:20:28 UTC t/t3NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Tests that interact with submodules a handful of times use `test_config_global` instead. Test scripts that rely on submodules throughout use a `git config --global` during a setup test towards the beginning of the script. Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
99f4abb Taylor Blau 29 July 2022, 19:20:03 UTC t/2NNNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Tests that interact with submodules a handful of times use `test_config_global` instead. Test scripts that rely on submodules throughout use a `git config --global` during a setup test towards the beginning of the script. Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
8a96dbc Taylor Blau 29 July 2022, 19:16:10 UTC t/t1NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Tests that interact with submodules a handful of times use `test_config_global` instead. Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
7de0c30 Taylor Blau 29 July 2022, 19:13:58 UTC t/lib-submodule-update.sh: allow local submodules To prepare for changing the default value of `protocol.file.allow` to "user", update the `prolog()` function in lib-submodule-update to allow submodules to be cloned over the file protocol. This is used by a handful of submodule-related test scripts, which themselves will have to tweak the value of `protocol.file.allow` in certain locations. Those will be done in subsequent commits. Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
6f054f9 Taylor Blau 28 July 2022, 21:35:17 UTC builtin/clone.c: disallow `--local` clones with symlinks When cloning a repository with `--local`, Git relies on either making a hardlink or copy to every file in the "objects" directory of the source repository. This is done through the callpath `cmd_clone()` -> `clone_local()` -> `copy_or_link_directory()`. The way this optimization works is by enumerating every file and directory recursively in the source repository's `$GIT_DIR/objects` directory, and then either making a copy or hardlink of each file. The only exception to this rule is when copying the "alternates" file, in which case paths are rewritten to be absolute before writing a new "alternates" file in the destination repo. One quirk of this implementation is that it dereferences symlinks when cloning. This behavior was most recently modified in 36596fd2df (clone: better handle symlinked files at .git/objects/, 2019-07-10), which attempted to support `--local` clones of repositories with symlinks in their objects directory in a platform-independent way. Unfortunately, this behavior of dereferencing symlinks (that is, creating a hardlink or copy of the source's link target in the destination repository) can be used as a component in attacking a victim by inadvertently exposing the contents of file stored outside of the repository. Take, for example, a repository that stores a Dockerfile and is used to build Docker images. When building an image, Docker copies the directory contents into the VM, and then instructs the VM to execute the Dockerfile at the root of the copied directory. This protects against directory traversal attacks by copying symbolic links as-is without dereferencing them. That is, if a user has a symlink pointing at their private key material (where the symlink is present in the same directory as the Dockerfile, but the key itself is present outside of that directory), the key is unreadable to a Docker image, since the link will appear broken from the container's point of view. This behavior enables an attack whereby a victim is convinced to clone a repository containing an embedded submodule (with a URL like "file:///proc/self/cwd/path/to/submodule") which has a symlink pointing at a path containing sensitive information on the victim's machine. If a user is tricked into doing this, the contents at the destination of those symbolic links are exposed to the Docker image at runtime. One approach to preventing this behavior is to recreate symlinks in the destination repository. But this is problematic, since symlinking the objects directory are not well-supported. (One potential problem is that when sharing, e.g. a "pack" directory via symlinks, different writers performing garbage collection may consider different sets of objects to be reachable, enabling a situation whereby garbage collecting one repository may remove reachable objects in another repository). Instead, prohibit the local clone optimization when any symlinks are present in the `$GIT_DIR/objects` directory of the source repository. Users may clone the repository again by prepending the "file://" scheme to their clone URL, or by adding the `--no-local` option to their `git clone` invocation. The directory iterator used by `copy_or_link_directory()` must no longer dereference symlinks (i.e., it *must* call `lstat()` instead of `stat()` in order to discover whether or not there are symlinks present). This has no bearing on the overall behavior, since we will immediately `die()` on encounter a symlink. Note that t5604.33 suggests that we do support local clones with symbolic links in the source repository's objects directory, but this was likely unintentional, or at least did not take into consideration the problem with sharing parts of the objects directory with symbolic links at the time. Update this test to reflect which options are and aren't supported. Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Taylor Blau <me@ttaylorr.com> 01 October 2022, 04:23:38 UTC
5b1c746 Johannes Schindelin 23 June 2022, 10:35:25 UTC Git 2.31.4 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 June 2022, 10:35:25 UTC
2f8809f Johannes Schindelin 23 June 2022, 10:35:23 UTC Sync with 2.30.5 * maint-2.30: Git 2.30.5 setup: tighten ownership checks post CVE-2022-24765 git-compat-util: allow root to access both SUDO_UID and root owned t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo 23 June 2022, 10:35:23 UTC
88b7be6 Johannes Schindelin 27 May 2022, 21:38:36 UTC Git 2.30.5 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 June 2022, 10:31:05 UTC
3b0bf27 Carlo Marcelo Arenas Belón 10 May 2022, 19:35:29 UTC setup: tighten ownership checks post CVE-2022-24765 8959555cee7 (setup_git_directory(): add an owner check for the top-level directory, 2022-03-02), adds a function to check for ownership of repositories using a directory that is representative of it, and ways to add exempt a specific repository from said check if needed, but that check didn't account for owership of the gitdir, or (when used) the gitfile that points to that gitdir. An attacker could create a git repository in a directory that they can write into but that is owned by the victim to work around the fix that was introduced with CVE-2022-24765 to potentially run code as the victim. An example that could result in privilege escalation to root in *NIX would be to set a repository in a shared tmp directory by doing (for example): $ git -C /tmp init To avoid that, extend the ensure_valid_ownership function to be able to check for all three paths. This will have the side effect of tripling the number of stat() calls when a repository is detected, but the effect is expected to be likely minimal, as it is done only once during the directory walk in which Git looks for a repository. Additionally make sure to resolve the gitfile (if one was used) to find the relevant gitdir for checking. While at it change the message printed on failure so it is clear we are referring to the repository by its worktree (or gitdir if it is bare) and not to a specific directory. Helped-by: Junio C Hamano <junio@pobox.com> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> 23 June 2022, 10:31:05 UTC
b779214 Junio C Hamano 26 May 2022, 21:51:32 UTC Merge branch 'cb/path-owner-check-with-sudo' With a recent update to refuse access to repositories of other people by default, "sudo make install" and "sudo git describe" stopped working. This series intends to loosen it while keeping the safety. * cb/path-owner-check-with-sudo: t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 June 2022, 10:31:04 UTC
6b11e3d Carlo Marcelo Arenas Belón 17 June 2022, 20:23:38 UTC git-compat-util: allow root to access both SUDO_UID and root owned Previous changes introduced a regression which will prevent root for accessing repositories owned by thyself if using sudo because SUDO_UID takes precedence. Loosen that restriction by allowing root to access repositories owned by both uid by default and without having to add a safe.directory exception. A previous workaround that was documented in the tests is no longer needed so it has been removed together with its specially crafted prerequisite. Helped-by: Johanness Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 June 2022, 21:03:08 UTC
b9063af Carlo Marcelo Arenas Belón 13 May 2022, 01:00:19 UTC t0034: add negative tests and allow git init to mostly work under sudo Add a support library that provides one function that can be used to run a "scriplet" of commands through sudo and that helps invoking sudo in the slightly awkward way that is required to ensure it doesn't block the call (if shell was allowed as tested in the prerequisite) and it doesn't run the command through a different shell than the one we intended. Add additional negative tests as suggested by Junio and that use a new workspace that is owned by root. Document a regression that was introduced by previous commits where root won't be able anymore to access directories they own unless SUDO_UID is removed from their environment. The tests document additional ways that this new restriction could be worked around and the documentation explains why it might be instead considered a feature, but a "fix" is planned for a future change. Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Phillip Wood <phillip.wood123@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 May 2022, 01:12:23 UTC
ae9abbb Carlo Marcelo Arenas Belón 13 May 2022, 01:00:18 UTC git-compat-util: avoid failing dir ownership checks if running privileged bdc77d1d685 (Add a function to determine whether a path is owned by the current user, 2022-03-02) checks for the effective uid of the running process using geteuid() but didn't account for cases where that user was root (because git was invoked through sudo or a compatible tool) and the original uid that repository trusted for its config was no longer known, therefore failing the following otherwise safe call: guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty [sudo] password for guy: fatal: unsafe repository ('/home/guy/Software/uncrustify' is owned by someone else) Attempt to detect those cases by using the environment variables that those tools create to keep track of the original user id, and do the ownership check using that instead. This assumes the environment the user is running on after going privileged can't be tampered with, and also adds code to restrict that the new behavior only applies if running as root, therefore keeping the most common case, which runs unprivileged, from changing, but because of that, it will miss cases where sudo (or an equivalent) was used to change to another unprivileged user or where the equivalent tool used to raise privileges didn't track the original id in a sudo compatible way. Because of compatibility with sudo, the code assumes that uid_t is an unsigned integer type (which is not required by the standard) but is used that way in their codebase to generate SUDO_UID. In systems where uid_t is signed, sudo might be also patched to NOT be unsigned and that might be able to trigger an edge case and a bug (as described in the code), but it is considered unlikely to happen and even if it does, the code would just mostly fail safely, so there was no attempt either to detect it or prevent it by the code, which is something that might change in the future, based on expected user feedback. Reported-by: Guy Maurel <guy.j@maurel.de> Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Randall Becker <rsbecker@nexbridge.com> Helped-by: Phillip Wood <phillip.wood123@gmail.com> Suggested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 May 2022, 01:12:23 UTC
5f1a3fe Carlo Marcelo Arenas Belón 13 May 2022, 01:00:17 UTC t: regression git needs safe.directory when using sudo Originally reported after release of v2.35.2 (and other maint branches) for CVE-2022-24765 and blocking otherwise harmless commands that were done using sudo in a repository that was owned by the user. Add a new test script with very basic support to allow running git commands through sudo, so a reproduction could be implemented and that uses only `git status` as a proxy of the issue reported. Note that because of the way sudo interacts with the system, a much more complete integration with the test framework will require a lot more work and that was therefore intentionally punted for now. The current implementation requires the execution of a special cleanup function which should always be kept as the last "test" or otherwise the standard cleanup functions will fail because they can't remove the root owned directories that are used. This also means that if failures are found while running, the specifics of the failure might not be kept for further debugging and if the test was interrupted, it will be necessary to clean the working directory manually before restarting by running: $ sudo rm -rf trash\ directory.t0034-root-safe-directory/ The test file also uses at least one initial "setup" test that creates a parallel execution directory under the "root" sub directory, which should be used as top level directory for all repositories that are used in this test file. Unlike all other tests the repository provided by the test framework should go unused. Special care should be taken when invoking commands through sudo, since the environment is otherwise independent from what the test framework setup and might have changed the values for HOME, SHELL and dropped several relevant environment variables for your test. Indeed `git status` was used as a proxy because it doesn't even require commits in the repository to work and usually doesn't require much from the environment to run, but a future patch will add calls to `git init` and that will fail to honor the default branch name, unless that setting is NOT provided through an environment variable (which means even a CI run could fail that test if enabled incorrectly). A new SUDO prerequisite is provided that does some sanity checking to make sure the sudo command that will be used allows for passwordless execution as root without restrictions and doesn't mess with git's execution path. This matches what is provided by the macOS agents that are used as part of GitHub actions and probably nowhere else. Most of those characteristics make this test mostly only suitable for CI, but it might be executed locally if special care is taken to provide for all of them in the local configuration and maybe making use of the sudo credential cache by first invoking sudo, entering your password if needed, and then invoking the test with: $ GIT_TEST_ALLOW_SUDO=YES ./t0034-root-safe-directory.sh If it fails to run, then it means your local setup wouldn't work for the test because of the configuration sudo has or other system settings, and things that might help are to comment out sudo's secure_path config, and make sure that the account you are using has no restrictions on the commands it can run through sudo, just like is provided for the user in the CI. For example (assuming a username of marta for you) something probably similar to the following entry in your /etc/sudoers (or equivalent) file: marta ALL=(ALL:ALL) NOPASSWD: ALL Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Phillip Wood <phillip.wood123@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 May 2022, 01:12:23 UTC
09f66d6 Junio C Hamano 13 April 2022, 22:21:08 UTC Git 2.31.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 April 2022, 22:21:08 UTC
17083c7 Junio C Hamano 13 April 2022, 20:31:29 UTC Git 2.30.4 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 April 2022, 20:31:29 UTC
0f85c4a Derrick Stolee 13 April 2022, 15:32:31 UTC setup: opt-out of check with safe.directory=* With the addition of the safe.directory in 8959555ce (setup_git_directory(): add an owner check for the top-level directory, 2022-03-02) released in v2.35.2, we are receiving feedback from a variety of users about the feature. Some users have a very large list of shared repositories and find it cumbersome to add this config for every one of them. In a more difficult case, certain workflows involve running Git commands within containers. The container boundary prevents any global or system config from communicating `safe.directory` values from the host into the container. Further, the container almost always runs as a different user than the owner of the directory in the host. To simplify the reactions necessary for these users, extend the definition of the safe.directory config value to include a possible '*' value. This value implies that all directories are safe, providing a single setting to opt-out of this protection. Note that an empty assignment of safe.directory clears all previous values, and this is already the case with the "if (!value || !*value)" condition. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 April 2022, 19:42:51 UTC
bb50ec3 Matheus Valadares 13 April 2022, 15:32:30 UTC setup: fix safe.directory key not being checked It seems that nothing is ever checking to make sure the safe directories in the configs actually have the key safe.directory, so some unrelated config that has a value with a certain directory would also make it a safe directory. Signed-off-by: Matheus Valadares <me@m28.io> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 April 2022, 19:42:51 UTC
e47363e Derrick Stolee 13 April 2022, 15:32:29 UTC t0033: add tests for safe.directory It is difficult to change the ownership on a directory in our test suite, so insert a new GIT_TEST_ASSUME_DIFFERENT_OWNER environment variable to trick Git into thinking we are in a differently-owned directory. This allows us to test that the config is parsed correctly. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 April 2022, 19:42:49 UTC
44de39c Johannes Schindelin 17 March 2022, 09:57:32 UTC Git 2.31.2 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 March 2022, 23:24:29 UTC
6a2381a Johannes Schindelin 17 March 2022, 09:57:31 UTC Sync with 2.30.3 * maint-2.30: Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user 23 March 2022, 23:24:29 UTC
cb95038 Johannes Schindelin 17 March 2022, 09:15:15 UTC Git 2.30.3 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 March 2022, 23:22:17 UTC
fdcad5a Johannes Schindelin 23 March 2022, 22:00:41 UTC Fix `GIT_CEILING_DIRECTORIES` with `C:\` and the likes When determining the length of the longest ancestor of a given path with respect to to e.g. `GIT_CEILING_DIRECTORIES`, we special-case the root directory by returning 0 (i.e. we pretend that the path `/` does not end in a slash by virtually stripping it). That is the correct behavior because when normalizing paths, the root directory is special: all other directory paths have their trailing slash stripped, but not the root directory's path (because it would become the empty string, which is not a legal path). However, this special-casing of the root directory in `longest_ancestor_length()` completely forgets about Windows-style root directories, e.g. `C:\`. These _also_ get normalized with a trailing slash (because `C:` would actually refer to the current directory on that drive, not necessarily to its root directory). In fc56c7b34b (mingw: accomodate t0060-path-utils for MSYS2, 2016-01-27), we almost got it right. We noticed that `longest_ancestor_length()` expects a slash _after_ the matched prefix, and if the prefix already ends in a slash, the normalized path won't ever match and -1 is returned. But then that commit went astray: The correct fix is not to adjust the _tests_ to expect an incorrect -1 when that function is fed a prefix that ends in a slash, but instead to treat such a prefix as if the trailing slash had been removed. Likewise, that function needs to handle the case where it is fed a path that ends in a slash (not only a prefix that ends in a slash): if it matches the prefix (plus trailing slash), we still need to verify that the path does not end there, otherwise the prefix is not actually an ancestor of the path but identical to it (and we need to return -1 in that case). With these two adjustments, we no longer need to play games in t0060 where we only add `$rootoff` if the passed prefix is different from the MSYS2 pseudo root, instead we also add it for the MSYS2 pseudo root itself. We do have to be careful to skip that logic entirely for Windows paths, though, because they do are not subject to that MSYS2 pseudo root treatment. This patch fixes the scenario where a user has set `GIT_CEILING_DIRECTORIES=C:\`, which would be ignored otherwise. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 March 2022, 23:21:08 UTC
8959555 Johannes Schindelin 02 March 2022, 11:23:04 UTC setup_git_directory(): add an owner check for the top-level directory It poses a security risk to search for a git directory outside of the directories owned by the current user. For example, it is common e.g. in computer pools of educational institutes to have a "scratch" space: a mounted disk with plenty of space that is regularly swiped where any authenticated user can create a directory to do their work. Merely navigating to such a space with a Git-enabled `PS1` when there is a maliciously-crafted `/scratch/.git/` can lead to a compromised account. The same holds true in multi-user setups running Windows, as `C:\` is writable to every authenticated user by default. To plug this vulnerability, we stop Git from accepting top-level directories owned by someone other than the current user. We avoid looking at the ownership of each and every directories between the current and the top-level one (if there are any between) to avoid introducing a performance bottleneck. This new default behavior is obviously incompatible with the concept of shared repositories, where we expect the top-level directory to be owned by only one of its legitimate users. To re-enable that use case, we add support for adding exceptions from the new default behavior via the config setting `safe.directory`. The `safe.directory` config setting is only respected in the system and global configs, not from repository configs or via the command-line, and can have multiple values to allow for multiple shared repositories. We are particularly careful to provide a helpful message to any user trying to use a shared repository. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 21 March 2022, 12:16:26 UTC
bdc77d1 Johannes Schindelin 02 March 2022, 10:06:24 UTC Add a function to determine whether a path is owned by the current user This function will be used in the next commit to prevent `setup_git_directory()` from discovering a repository in a directory that is owned by someone other than the current user. Note: We cannot simply use `st.st_uid` on Windows just like we do on Linux and other Unix-like platforms: according to https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions this field is always zero on Windows (because Windows' idea of a user ID does not fit into a single numerical value). Therefore, we have to do something a little involved to replicate the same functionality there. Also note: On Windows, a user's home directory is not actually owned by said user, but by the administrator. For all practical purposes, it is under the user's control, though, therefore we pretend that it is owned by the user. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 21 March 2022, 12:16:26 UTC
2a9a586 Johannes Schindelin 17 March 2022, 11:52:12 UTC Merge branch 'cb/mingw-gmtime-r' Build fix on Windows. * cb/mingw-gmtime-r: mingw: avoid fallback for {local,gm}time_r() Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 March 2022, 11:52:12 UTC
6e7ad1e Carlo Marcelo Arenas Belón 27 November 2021, 10:15:32 UTC mingw: avoid fallback for {local,gm}time_r() mingw-w64's pthread_unistd.h had a bug that mistakenly (because there is no support for the *lockfile() functions required[1]) defined _POSIX_THREAD_SAFE_FUNCTIONS and that was being worked around since 3ecd153a3b (compat/mingw: support MSys2-based MinGW build, 2016-01-14). The bug was fixed in winphtreads, but as a side effect, leaves the reentrant functions from time.h no longer visible and therefore breaks the build. Since the intention all along was to avoid using the fallback functions, formalize the use of POSIX by setting the corresponding feature flag and compile out the implementation for the fallback functions. [1] https://unix.org/whitepapers/reentrant.html Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 March 2022, 11:52:12 UTC
48bf2fa Junio C Hamano 19 March 2021, 22:07:58 UTC Git 2.31.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> 26 March 2021, 21:49:41 UTC
ef486a9 Junio C Hamano 19 March 2021, 22:25:40 UTC Merge branch 'tb/git-mv-icase-fix' Fix a corner case bug in "git mv" on case insensitive systems, which was introduced in 2.29 timeframe. * tb/git-mv-icase-fix: git mv foo FOO ; git mv foo bar gave an assert 19 March 2021, 22:25:40 UTC
bfcc6e2 Junio C Hamano 19 March 2021, 22:25:39 UTC Merge branch 'rs/xcalloc-takes-nelem-first' Code cleanup. * rs/xcalloc-takes-nelem-first: fix xcalloc() argument order 19 March 2021, 22:25:39 UTC
af10702 Junio C Hamano 19 March 2021, 22:25:39 UTC Merge branch 'ah/make-fuzz-all-doc-update' Update insn in Makefile comments to run fuzz-all target. * ah/make-fuzz-all-doc-update: Makefile: update 'make fuzz-all' docs to reflect modern clang 19 March 2021, 22:25:39 UTC
c691e91 Junio C Hamano 19 March 2021, 22:25:38 UTC Merge branch 'jk/slimmed-down' Unused code removal. * jk/slimmed-down: vcs-svn: remove header files as well 19 March 2021, 22:25:38 UTC
92ccd7b Junio C Hamano 19 March 2021, 22:25:38 UTC Merge branch 'rs/calloc-array' CALLOC_ARRAY() macro replaces many uses of xcalloc(). * rs/calloc-array: cocci: allow xcalloc(1, size) use CALLOC_ARRAY git-compat-util.h: drop trailing semicolon from macro definition 19 March 2021, 22:25:38 UTC
a8a0ac3 Junio C Hamano 19 March 2021, 22:25:38 UTC Merge branch 'rs/avoid-null-statement-after-macro-call' Fix macros that can silently inject unintended null-statements. * rs/avoid-null-statement-after-macro-call: mem-pool: drop trailing semicolon from macro definition block-sha1: drop trailing semicolon from macro definition 19 March 2021, 22:25:38 UTC
948e8ac Junio C Hamano 19 March 2021, 22:25:38 UTC Merge branch 'km/config-doc-typofix' Docfix. * km/config-doc-typofix: config.txt: add missing period 19 March 2021, 22:25:38 UTC
cc930b7 Junio C Hamano 19 March 2021, 22:25:37 UTC Merge branch 'jt/clone-unborn-head' Test fix. * jt/clone-unborn-head: t5606: run clone branch name test with protocol v2 19 March 2021, 22:25:38 UTC
1dd4e74 Junio C Hamano 19 March 2021, 22:25:37 UTC Merge branch 'js/fsmonitor-unpack-fix' The data structure used by fsmonitor interface was not properly duplicated during an in-core merge, leading to use-after-free etc. * js/fsmonitor-unpack-fix: fsmonitor: do not forget to release the token in `discard_index()` fsmonitor: fix memory corruption in some corner cases 19 March 2021, 22:25:37 UTC
35381b1 Junio C Hamano 19 March 2021, 22:25:37 UTC Merge branch 'jk/bisect-peel-tag-fix' "git bisect" reimplemented more in C during 2.30 timeframe did not take an annotated tag as a good/bad endpoint well. This regression has been corrected. * jk/bisect-peel-tag-fix: bisect: peel annotated tags to commits 19 March 2021, 22:25:37 UTC
8779c14 Junio C Hamano 19 March 2021, 22:25:37 UTC Merge branch 'jh/fsmonitor-prework' The fsmonitor interface read from its input without making sure there is something to read from. This bug is new in 2.31 timeframe. * jh/fsmonitor-prework: fsmonitor: avoid global-buffer-overflow READ when checking trivial response 19 March 2021, 22:25:37 UTC
eabacfd Junio C Hamano 19 March 2021, 22:25:37 UTC Merge branch 'jc/calloc-fix' Code clean-up. * jc/calloc-fix: xcalloc: use CALLOC_ARRAY() when applicable 19 March 2021, 22:25:37 UTC
4abc578 Johannes Schindelin 17 March 2021, 15:30:49 UTC fsmonitor: do not forget to release the token in `discard_index()` In 56c6910028a (fsmonitor: change last update timestamp on the index_state to opaque token, 2020-01-07), we forgot to adjust `discard_index()` to release the "last-update" token: it is no longer a 64-bit number, but a free-form string that has been allocated. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 March 2021, 19:19:28 UTC
3dfd305 Johannes Schindelin 17 March 2021, 15:30:48 UTC fsmonitor: fix memory corruption in some corner cases In 56c6910028a (fsmonitor: change last update timestamp on the index_state to opaque token, 2020-01-07), we forgot to adjust the part of `unpack_trees()` that copies the FSMonitor "last-update" information that we copy from the source index to the result index since 679f2f9fdd2 (unpack-trees: skip stat on fsmonitor-valid files, 2019-11-20). Since the "last-update" information is no longer a 64-bit number, but a free-form string that has been allocated, we need to duplicate it rather than just copying it. This is important because there _are_ cases when `unpack_trees()` will perform a oneway merge that implicitly calls `refresh_fsmonitor()` (which will allocate that "last-update" token). This happens _after_ that token was copied into the result index. However, we _then_ call `check_updates()` on that index, which will _also_ call `refresh_fsmonitor()`, accessing the "last-update" string, which by now would be released already. In the instance that lead to this patch, this caused a segmentation fault during a lengthy, complicated rebase involving the todo command `reset` that (crucially) had to updated many files. Unfortunately, it seems very hard to trigger that crash, therefore this patch is not accompanied by a regression test. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 March 2021, 19:19:26 UTC
cfd409e Kyle Meyer 16 March 2021, 14:40:40 UTC config.txt: add missing period Signed-off-by: Kyle Meyer <kyle@kyleam.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 March 2021, 18:25:15 UTC
7730f85 Jeff King 16 March 2021, 15:15:55 UTC bisect: peel annotated tags to commits This patch fixes a bug where git-bisect doesn't handle receiving annotated tags as "git bisect good <tag>", etc. It's a regression in 27257bc466 (bisect--helper: reimplement `bisect_state` & `bisect_head` shell functions in C, 2020-10-15). The original shell code called: sha=$(git rev-parse --verify "$rev^{commit}") || die "$(eval_gettext "Bad rev input: \$rev")" which will peel the input to a commit (or complain if that's not possible). But the C code just calls get_oid(), which will yield the oid of the tag. The fix is to peel to a commit. The error message here is a little non-idiomatic for Git (since it starts with a capital). I've mostly left it, as it matches the other converted messages (like the "Bad rev input" we print when get_oid() fails), though I did add an indication that it was the peeling that was the problem. It might be worth taking a pass through this converted code to modernize some of the error messages. Note also that the test does a bare "grep" (not i18ngrep) on the expected "X is the first bad commit" output message. This matches the rest of the test script. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 March 2021, 18:24:08 UTC
5f70859 Jonathan Tan 17 March 2021, 15:42:00 UTC t5606: run clone branch name test with protocol v2 4f37d45706 ("clone: respect remote unborn HEAD", 2021-02-05) introduces a new feature (if the remote has an unborn HEAD, e.g. when the remote repository is empty, use it as the name of the branch) that only works in protocol v2, but did not ensure that one of its tests always uses protocol v2, and thus that test would fail if GIT_TEST_PROTOCOL_VERSION=0 (or 1) is used. Therefore, add "-c protocol.version=2" to the appropriate test. (The rest of the tests from that commit have "-c protocol.version=2" already added.) Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 March 2021, 18:19:36 UTC
116affa René Scharfe 13 March 2021, 16:17:37 UTC mem-pool: drop trailing semicolon from macro definition Allow BLOCK_GROWTH_SIZE to be used like an integer literal by removing the trailing semicolon from its definition. Also wrap the expression in parentheses, to allow it to be used with operators without leading to unexpected results. It doesn't matter for the current use site, but make it follow standard macro rules anyway to avoid future surprises. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 March 2021, 17:20:16 UTC
3d8cbbf René Scharfe 13 March 2021, 16:17:30 UTC block-sha1: drop trailing semicolon from macro definition 23119ffb4e (block-sha1: put expanded macro parameters in parentheses, 2012-07-22) added a trailing semicolon to the definition of SHA_MIX without explanation. It doesn't matter with the current code, but make sure to avoid potential surprises by removing it again. This allows the macro to be used almost like a function: Users can combine it with operators of their choice, but still must not pass an expression with side-effects as a parameter, as it would be evaluated multiple times. Signed-off-by: René Scharfe <l.s.r@web.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 March 2021, 17:20:01 UTC
097ea2c Andrzej Hunt 15 March 2021, 16:39:23 UTC fsmonitor: avoid global-buffer-overflow READ when checking trivial response query_result can be be an empty strbuf (STRBUF_INIT) - in that case trying to read 3 bytes triggers a buffer overflow read (as query_result.buf = '\0'). Therefore we need to check query_result's length before trying to read 3 bytes. This overflow was introduced in: 940b94f35c (fsmonitor: log invocation of FSMonitor hook to trace2, 2021-02-03) It was found when running the test-suite against ASAN, and can be most easily reproduced with the following command: make GIT_TEST_OPTS="-v" DEFAULT_TEST_TARGET="t7519-status-fsmonitor.sh" \ SANITIZE=address DEVELOPER=1 test ==2235==ERROR: AddressSanitizer: global-buffer-overflow on address 0x0000019e6e5e at pc 0x00000043745c bp 0x7fffd382c520 sp 0x7fffd382bcc8 READ of size 3 at 0x0000019e6e5e thread T0 #0 0x43745b in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long), void const*, void const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:842:7 #1 0x43786d in bcmp /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:887:10 #2 0x80b146 in fsmonitor_is_trivial_response /home/ahunt/oss-fuzz/git/fsmonitor.c:192:10 #3 0x80b146 in query_fsmonitor /home/ahunt/oss-fuzz/git/fsmonitor.c:175:7 #4 0x80a749 in refresh_fsmonitor /home/ahunt/oss-fuzz/git/fsmonitor.c:267:21 #5 0x80bad1 in tweak_fsmonitor /home/ahunt/oss-fuzz/git/fsmonitor.c:429:4 #6 0x90f040 in read_index_from /home/ahunt/oss-fuzz/git/read-cache.c:2321:3 #7 0x8e5d08 in repo_read_index_preload /home/ahunt/oss-fuzz/git/preload-index.c:164:15 #8 0x52dd45 in prepare_index /home/ahunt/oss-fuzz/git/builtin/commit.c:363:6 #9 0x52a188 in cmd_commit /home/ahunt/oss-fuzz/git/builtin/commit.c:1588:15 #10 0x4ce77e in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11 #11 0x4ccb18 in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3 #12 0x4cb01c in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4 #13 0x4cb01c in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19 #14 0x6aca8d in main /home/ahunt/oss-fuzz/git/common-main.c:52:11 #15 0x7fb027bf5349 in __libc_start_main (/lib64/libc.so.6+0x24349) #16 0x4206b9 in _start /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120 0x0000019e6e5e is located 2 bytes to the left of global variable 'strbuf_slopbuf' defined in 'strbuf.c:51:6' (0x19e6e60) of size 1 'strbuf_slopbuf' is ascii string '' 0x0000019e6e5e is located 126 bytes to the right of global variable 'signals' defined in 'sigchain.c:11:31' (0x19e6be0) of size 512 SUMMARY: AddressSanitizer: global-buffer-overflow /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:842:7 in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long), void const*, void const*, unsigned long) Shadow bytes around the buggy address: 0x000080334d70: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 0x000080334d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x000080334d90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x000080334da0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x000080334db0: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 =>0x000080334dc0: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9[f9]01 f9 f9 f9 0x000080334dd0: f9 f9 f9 f9 03 f9 f9 f9 f9 f9 f9 f9 02 f9 f9 f9 0x000080334de0: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 0x000080334df0: f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 0x000080334e00: f9 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 01 f9 f9 f9 0x000080334e10: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc Signed-off-by: Andrzej Hunt <ajrhunt@google.com> Acked-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 March 2021, 17:00:20 UTC
1c57cc7 Junio C Hamano 16 March 2021, 00:56:07 UTC cocci: allow xcalloc(1, size) Allocating a pre-cleared single element is quite common and it is misleading to use CALLOC_ARRAY(); these allocations that would be affected without this change are not allocating an array. Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 March 2021, 00:56:07 UTC
486f4bd Junio C Hamano 15 March 2021, 22:05:04 UTC xcalloc: use CALLOC_ARRAY() when applicable These are for codebase before Git 2.31 Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 March 2021, 00:51:10 UTC
a5828ae Junio C Hamano 15 March 2021, 18:51:51 UTC Git 2.31 Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 March 2021, 18:51:51 UTC
8775279 Junio C Hamano 14 March 2021, 23:01:41 UTC Merge branch 'jn/mergetool-hideresolved-is-optional' Disable the recent mergetool's hideresolved feature by default for backward compatibility and safety. * jn/mergetool-hideresolved-is-optional: doc: describe mergetool configuration in git-mergetool(1) mergetool: do not enable hideResolved by default 14 March 2021, 23:01:41 UTC
074d162 Junio C Hamano 14 March 2021, 23:01:40 UTC Merge branch 'tb/pack-revindex-on-disk' Fix for a topic in 'master'. * tb/pack-revindex-on-disk: pack-revindex.c: don't close unopened file descriptors 14 March 2021, 23:01:41 UTC
5be1c70 Junio C Hamano 14 March 2021, 22:50:36 UTC Merge tag 'l10n-2.31.0-rnd2' of git://github.com/git-l10n/git-po l10n for Git 2.31.0 round 2 * tag 'l10n-2.31.0-rnd2' of git://github.com/git-l10n/git-po: l10n: zh_CN: for git v2.31.0 l10n round 1 and 2 l10n: de.po: Update German translation for Git v2.31.0 l10n: pt_PT: add Portuguese translations part 1 l10n: vi.po(5104t): for git v2.31.0 l10n round 2 l10n: es: 2.31.0 round 2 l10n: Add translation team info l10n: start Indonesian translation l10n: zh_TW.po: v2.31.0 round 2 (15 untranslated) l10n: bg.po: Updated Bulgarian translation (5104t) l10n: fr: v2.31 rnd 2 l10n: tr: v2.31.0-rc1 l10n: sv.po: Update Swedish translation (5104t0f0u) l10n: git.pot: v2.31.0 round 2 (9 new, 8 removed) l10n: tr: v2.31.0-rc0 l10n: sv.po: Update Swedish translation (5103t0f0u) l10n: pl.po: Update translation l10n: fr: v2.31.0 rnd 1 l10n: git.pot: v2.31.0 round 1 (155 new, 89 removed) l10n: Update Catalan translation l10n: ru.po: update Russian translation 14 March 2021, 22:50:36 UTC
8588aa8 René Scharfe 14 March 2021, 14:37:39 UTC vcs-svn: remove header files as well fc47391e24 (drop vcs-svn experiment, 2020-08-13) removed most vcs-svn files. Drop the remaining header files as well, as they are no longer used. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 March 2021, 22:48:23 UTC
473eb54 Jiang Xin 04 March 2021, 14:44:43 UTC l10n: zh_CN: for git v2.31.0 l10n round 1 and 2 Translate 161 new messages (5104t0f0u) for git 2.31.0. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> 14 March 2021, 16:05:25 UTC
4bc948a Jiang Xin 14 March 2021, 16:04:47 UTC Merge branch 'master' of github.com:vnwildman/git * 'master' of github.com:vnwildman/git: l10n: vi.po(5104t): for git v2.31.0 l10n round 2 14 March 2021, 16:04:47 UTC
e196890 Jiang Xin 14 March 2021, 14:35:44 UTC Merge branch 'l10n/zh_TW/210301' of github.com:l10n-tw/git-po * 'l10n/zh_TW/210301' of github.com:l10n-tw/git-po: l10n: zh_TW.po: v2.31.0 round 2 (15 untranslated) 14 March 2021, 14:35:44 UTC
84bc814 Jiang Xin 14 March 2021, 14:35:17 UTC Merge branch 'po-id' of github.com:bagasme/git-po * 'po-id' of github.com:bagasme/git-po: l10n: Add translation team info l10n: start Indonesian translation 14 March 2021, 14:35:17 UTC
bd5fba8 Jiang Xin 14 March 2021, 14:34:46 UTC Merge branch 'master' of github.com:Softcatala/git-po * 'master' of github.com:Softcatala/git-po: l10n: Update Catalan translation 14 March 2021, 14:34:46 UTC
2d89752 Jiang Xin 14 March 2021, 14:34:12 UTC Merge branch 'russian-l10n' of github.com:DJm00n/git-po-ru * 'russian-l10n' of github.com:DJm00n/git-po-ru: l10n: ru.po: update Russian translation 14 March 2021, 14:34:12 UTC
799df2e Jiang Xin 14 March 2021, 14:33:26 UTC Merge branch 'pt-PT' of github.com:git-l10n-pt-PT/git-po * 'pt-PT' of github.com:git-l10n-pt-PT/git-po: l10n: pt_PT: add Portuguese translations part 1 14 March 2021, 14:33:26 UTC
ca56dad René Scharfe 13 March 2021, 16:17:22 UTC use CALLOC_ARRAY Add and apply a semantic patch for converting code that open-codes CALLOC_ARRAY to use it instead. It shortens the code and infers the element size automatically. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 March 2021, 00:00:09 UTC
f112149 René Scharfe 13 March 2021, 16:10:47 UTC git-compat-util.h: drop trailing semicolon from macro definition Make CALLOC_ARRAY usable like a function by requiring callers to supply the trailing semicolon, which all of the current ones already do. With the extra semicolon e.g. the following code wouldn't compile because it disconnects the "else" from the "if": if (condition) CALLOC_ARRAY(ptr, n); else whatever(); Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 March 2021, 23:56:13 UTC
5320406 Jonathan Nieder 13 March 2021, 08:41:33 UTC doc: describe mergetool configuration in git-mergetool(1) In particular, this describes mergetool.hideResolved, which can help users discover this setting (either because it may be useful to them or in order to understand mergetool's behavior if they have forgotten setting it in the past). Tested by running make -C Documentation git-mergetool.1 man Documentation/git-mergetool.1 and reading through the page. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 March 2021, 23:34:32 UTC
b2a51c1 Jonathan Nieder 13 March 2021, 08:38:48 UTC mergetool: do not enable hideResolved by default When 98ea309b3f (mergetool: add hideResolved configuration, 2021-02-09) introduced the mergetool.hideResolved setting to reduce the clutter in viewing non-conflicted sections of files in a mergetool, it enabled it by default, explaining: No adverse effects were noted in a small survey of popular mergetools[1] so this behavior defaults to `true`. In practice, alas, adverse effects do appear. A few issues: 1. No indication is shown in the UI that the base, local, and remote versions shown have been modified by additional resolution. This is inherent in the design: the idea of mergetool.hideResolved is to convince a mergetool that expects pristine local, base, and remote files to show partially resolved verisons of those files instead; there is no additional source of information accessible to the mergetool to see where the resolution has happened. (By contrast, a mergetool generating the partial resolution from conflict markers for itself would be able to hilight the resolved sections with a different color.) A user accustomed to seeing the files without partial resolution gets no indication that this behavior has changed when they upgrade Git. 2. If the computed merge did not line up the files correctly (for example due to repeated sections in the file), the partially resolved files can be misleading and do not have enough information to reconstruct what happened and compute the correct merge result. 3. Resolving a conflict can involve information beyond the textual conflict. For example, if the local and remote versions added overlapping functionality in different ways, seeing the full unresolved versions of each alongside the base gives information about each side's intent that makes it possible to come up with a resolution that combines those two intents. By contrast, when starting with partially resolved versions of those files, one can produce a subtly wrong resolution that includes redundant extra code added by one side that is not needed in the approach taken on the other. All that said, a user wanting to focus on textual conflicts with reduced clutter can still benefit from mergetool.hideResolved=true as a way to deemphasize sections of the code that resolve cleanly without requiring any changes to the invoked mergetool. The caveats described above are reduced when the user has explicitly turned this on, because then the user is aware of them. Flip the default to 'false'. Reported-by: Dana Dahlstrom <dahlstrom@google.com> Helped-by: Seth House <seth@eseth.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 March 2021, 23:30:29 UTC
13d7ab6 Junio C Hamano 09 March 2021, 00:09:43 UTC Git 2.31-rc2 09 March 2021, 00:09:43 UTC
56a5765 Junio C Hamano 09 March 2021, 00:09:07 UTC Sync with Git 2.30.2 for CVE-2021-21300 Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 March 2021, 00:09:07 UTC
6c46f86 Junio C Hamano 09 March 2021, 00:04:47 UTC Merge branch 'jt/transfer-fsck-across-packs-fix' The code to fsck objects received across multiple packs during a single git fetch session has been broken when the packfile URI feature was in use. A workaround has been added by disabling the codepath to avoid keeping a packfile that is too small. * jt/transfer-fsck-across-packs-fix: fetch-pack: do not mix --pack_header and packfile uri 09 March 2021, 00:04:47 UTC
8348451 Matthias Rüster 28 February 2021, 14:40:23 UTC l10n: de.po: Update German translation for Git v2.31.0 Reviewed-by: Ralf Thielow <ralf.thielow@gmail.com> Reviewed-by: Phillip Szelat <phillip.szelat@gmail.com> Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com> 08 March 2021, 18:49:33 UTC
68b5c3a Andrzej Hunt 08 March 2021, 17:14:42 UTC Makefile: update 'make fuzz-all' docs to reflect modern clang Clang no longer produces a libFuzzer.a. Instead, you can include libFuzzer by using -fsanitize=fuzzer. Therefore we should use that in the example command for building fuzzers. We also add -fsanitize=fuzzer-no-link to the CFLAGS to ensure that all the required instrumentation is added when compiling git [1], and remove -fsanitize-coverage=trace-pc-guard as it is deprecated. I happen to have tested with LLVM 11 - however -fsanitize=fuzzer appears to work in a wide range of reasonably modern clangs. (On my system: what used to be libFuzzer.a now lives under the following path, which is tricky albeit not impossible for a novice such as myself to find: /usr/lib64/clang/11.0.0/lib/linux/libclang_rt.fuzzer-x86_64.a ) [1] https://releases.llvm.org/11.0.0/docs/LibFuzzer.html#fuzzer-usage Signed-off-by: Andrzej Hunt <ajrhunt@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 March 2021, 18:26:25 UTC
241b5d3 René Scharfe 06 March 2021, 11:26:19 UTC fix xcalloc() argument order Pass the number of elements first and ther size second, as expected by xcalloc(). Provide a semantic patch, which was actually used to generate the rest of this patch. The semantic patch would generate flip-flop diffs if both arguments are sizeofs. We don't have such a case, and it's hard to imagine the usefulness of such an allocation. If it ever occurs then we could deal with it by duplicating the rule in the semantic patch to make it cancel itself out, or we could change the code to use CALLOC_ARRAY. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 March 2021, 17:45:04 UTC
408985d Daniel Santos 22 October 2020, 09:52:22 UTC l10n: pt_PT: add Portuguese translations part 1 * Newlines corrected. * Add concept translation table. * Translated some. * Corrected some. * Corrected some 'Negation of Emptiness'. Signed-off-by: Daniel Santos <hello@brighterdan.com> 08 March 2021, 15:21:51 UTC
1369935 Tran Ngoc Quan 08 March 2021, 02:00:45 UTC l10n: vi.po(5104t): for git v2.31.0 l10n round 2 Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com> 08 March 2021, 02:03:04 UTC
b0adcc3 Christopher Diaz Riveros 07 March 2021, 23:31:14 UTC l10n: es: 2.31.0 round 2 Signed-off-by: Christopher Diaz Riveros <christopher.diaz.riv@gmail.com> 07 March 2021, 23:31:14 UTC
c21ad4d Bagas Sanjaya 02 March 2021, 06:38:43 UTC l10n: Add translation team info Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> 07 March 2021, 12:38:29 UTC
8c4abfb Bagas Sanjaya 20 February 2021, 11:21:42 UTC l10n: start Indonesian translation * Initialize PO file * Translate init-db.c * Translate wt-status.c * Translate builtin/clone.c * Translate builtin/checkout.c * Translate builtin/fetch.c * Complete core translations: * builtin/remote.c * builtin/index-pack.c * push.c * reset.c * Sync with l10n upstream Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> 07 March 2021, 12:38:07 UTC
2aec3bc Jonathan Tan 05 March 2021, 01:16:20 UTC fetch-pack: do not mix --pack_header and packfile uri When fetching (as opposed to cloning) from a repository with packfile URIs enabled, an error like this may occur: fatal: pack has bad object at offset 12: unknown object type 5 fatal: finish_http_pack_request gave result -1 fatal: fetch-pack: expected keep then TAB at start of http-fetch output This bug was introduced in b664e9ffa1 ("fetch-pack: with packfile URIs, use index-pack arg", 2021-02-22), when the index-pack args used when processing the inline packfile of a fetch response and when processing packfile URIs were unified. This bug happens because fetch, by default, partially reads (and consumes) the header of the inline packfile to determine if it should store the downloaded objects as a packfile or loose objects, and thus passes --pack_header=<...> to index-pack to inform it that some bytes are missing. However, when it subsequently fetches the additional packfiles linked by URIs, it reuses the same index-pack arguments, thus wrongly passing --index-pack-arg=--pack_header=<...> when no bytes are missing. This does not happen when cloning because "git clone" always passes do_keep, which instructs the fetch mechanism to always retain the packfile, eliminating the need to read the header. There are a few ways to fix this, including filtering out pack_header arguments when downloading the additional packfiles, but I decided to stick to always using index-pack throughout when packfile URIs are present - thus, Git no longer needs to read the bytes, and no longer needs --pack_header here. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 March 2021, 23:04:09 UTC
8278f87 Yi-Jyun Pan 01 March 2021, 13:17:36 UTC l10n: zh_TW.po: v2.31.0 round 2 (15 untranslated) Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com> 05 March 2021, 18:43:34 UTC
2f176de Alexander Shopov 26 February 2021, 07:00:26 UTC l10n: bg.po: Updated Bulgarian translation (5104t) Signed-off-by: Alexander Shopov <ash@kambanaria.org> 05 March 2021, 11:12:34 UTC
1ecef02 Jiang Xin 05 March 2021, 05:47:07 UTC Merge branch 'fr_next' of github.com:jnavila/git * 'fr_next' of github.com:jnavila/git: l10n: fr: v2.31 rnd 2 05 March 2021, 05:47:07 UTC
5b888ad Jiang Xin 05 March 2021, 05:46:25 UTC Merge branch 'master' of github.com:nafmo/git-l10n-sv * 'master' of github.com:nafmo/git-l10n-sv: l10n: sv.po: Update Swedish translation (5104t0f0u) 05 March 2021, 05:46:25 UTC
be7935e Junio C Hamano 04 March 2021, 23:42:50 UTC Merged the open-eintr workaround for macOS Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 March 2021, 23:42:50 UTC
58d581c Elijah Newren 04 March 2021, 22:51:32 UTC Documentation/RelNotes: improve release note for rename detection work There were some early changes in the 2.31 cycle to optimize some setup in diffcore-rename.c[1], some later changes to measure performance[2], and finally some significant changes to improve rename detection performance. The final one was merged with the note Performance optimization work on the rename detection continues. That works for the commit log, but feels misleading as a release note since all the changes were within one cycle. Simplify this to just Performance improvements for rename detection. The former wording could be seen as hinting that more performance improvements will come in 2.32, which is true, but we can just cover those in the 2.32 release notes when the time comes. [1] a5ac31b5b1 (Merge branch 'en/diffcore-rename', 2021-01-25) [2] d3a035b055 (Merge branch 'en/merge-ort-perf', 2021-02-11) [3] 12bd17521c (Merge branch 'en/diffcore-rename', 2021-03-01) Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 March 2021, 23:38:11 UTC
921846f Junio C Hamano 04 March 2021, 23:34:45 UTC Merge branch 'jk/open-returns-eintr' Work around platforms whose open() is reported to return EINTR (it shouldn't, as we do our signals with SA_RESTART). * jk/open-returns-eintr: config.mak.uname: enable OPEN_RETURNS_EINTR for macOS Big Sur Makefile: add OPEN_RETURNS_EINTR knob 04 March 2021, 23:34:45 UTC
068cb92 Jean-Noël Avila 04 March 2021, 20:53:45 UTC l10n: fr: v2.31 rnd 2 Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> 04 March 2021, 20:53:45 UTC
85c787f Junio C Hamano 04 March 2021, 20:38:50 UTC Merge https://github.com/prati0100/git-gui * https://github.com/prati0100/git-gui: Revert "git-gui: remove lines starting with the comment character" 04 March 2021, 20:38:50 UTC
f6a7e89 Emir Sarı 04 March 2021, 19:29:24 UTC l10n: tr: v2.31.0-rc1 Signed-off-by: Emir Sarı <bitigchi@me.com> 04 March 2021, 19:29:24 UTC
back to top