Skip to main content

Browse the archive

https://github.com/git/git
31 May 2024, 23:06:24 UTC
sort by:
Revision Author Date Message Commit Date
239bd35 Junio C Hamano 31 May 2024, 00:03:31 UTC Git 2.42.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 31 May 2024, 00:03:31 UTC
18df122 Junio C Hamano 31 May 2024, 00:00:57 UTC Merge branch 'fixes/2.45.1/2.42' into maint-2.42 * fixes/2.45.1/2.42: Revert "fsck: warn about symlink pointing inside a gitdir" Revert "Add a helper function to compare file contents" clone: drop the protections where hooks aren't run tests: verify that `clone -c core.hooksPath=/dev/null` works again Revert "core.hooksPath: add some protection while cloning" init: use the correct path of the templates directory again hook: plug a new memory leak ci: stop installing "gcc-13" for osx-gcc ci: avoid bare "gcc" for osx-gcc job ci: drop mention of BREW_INSTALL_PACKAGES variable send-email: avoid creating more than one Term::ReadLine object send-email: drop FakeTerm hack 31 May 2024, 00:00:57 UTC
0dc9cad Junio C Hamano 31 May 2024, 00:00:29 UTC Git 2.41.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 31 May 2024, 00:00:29 UTC
f20b96a Junio C Hamano 30 May 2024, 23:58:12 UTC Merge branch 'fixes/2.45.1/2.41' into maint-2.41 * fixes/2.45.1/2.41: Revert "fsck: warn about symlink pointing inside a gitdir" Revert "Add a helper function to compare file contents" clone: drop the protections where hooks aren't run tests: verify that `clone -c core.hooksPath=/dev/null` works again Revert "core.hooksPath: add some protection while cloning" init: use the correct path of the templates directory again hook: plug a new memory leak ci: stop installing "gcc-13" for osx-gcc ci: avoid bare "gcc" for osx-gcc job ci: drop mention of BREW_INSTALL_PACKAGES variable send-email: avoid creating more than one Term::ReadLine object send-email: drop FakeTerm hack 30 May 2024, 23:58:12 UTC
dbecc61 Junio C Hamano 30 May 2024, 23:57:31 UTC Git 2.40.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 May 2024, 23:57:31 UTC
75e7cd2 Junio C Hamano 30 May 2024, 23:54:42 UTC Merge branch 'fixes/2.45.1/2.40' into maint-2.40 * fixes/2.45.1/2.40: Revert "fsck: warn about symlink pointing inside a gitdir" Revert "Add a helper function to compare file contents" clone: drop the protections where hooks aren't run tests: verify that `clone -c core.hooksPath=/dev/null` works again Revert "core.hooksPath: add some protection while cloning" init: use the correct path of the templates directory again hook: plug a new memory leak ci: stop installing "gcc-13" for osx-gcc ci: avoid bare "gcc" for osx-gcc job ci: drop mention of BREW_INSTALL_PACKAGES variable send-email: avoid creating more than one Term::ReadLine object send-email: drop FakeTerm hack 30 May 2024, 23:54:42 UTC
cc7d11c Junio C Hamano 30 May 2024, 23:52:52 UTC Git 2.39.5 30 May 2024, 23:52:52 UTC
7eb9152 Junio C Hamano 30 May 2024, 23:38:58 UTC Merge branch 'jc/fix-2.45.1-and-friends-for-2.39' into maint-2.39 * jc/fix-2.45.1-and-friends-for-2.39: Revert "fsck: warn about symlink pointing inside a gitdir" Revert "Add a helper function to compare file contents" clone: drop the protections where hooks aren't run tests: verify that `clone -c core.hooksPath=/dev/null` works again Revert "core.hooksPath: add some protection while cloning" init: use the correct path of the templates directory again hook: plug a new memory leak ci: stop installing "gcc-13" for osx-gcc ci: avoid bare "gcc" for osx-gcc job ci: drop mention of BREW_INSTALL_PACKAGES variable send-email: avoid creating more than one Term::ReadLine object send-email: drop FakeTerm hack 30 May 2024, 23:38:58 UTC
73339e4 Junio C Hamano 24 May 2024, 23:57:43 UTC Merge branch 'fixes/2.45.1/2.41' into fixes/2.45.1/2.42 * fixes/2.45.1/2.41: Revert "fsck: warn about symlink pointing inside a gitdir" Revert "Add a helper function to compare file contents" clone: drop the protections where hooks aren't run tests: verify that `clone -c core.hooksPath=/dev/null` works again Revert "core.hooksPath: add some protection while cloning" init: use the correct path of the templates directory again hook: plug a new memory leak ci: stop installing "gcc-13" for osx-gcc ci: avoid bare "gcc" for osx-gcc job ci: drop mention of BREW_INSTALL_PACKAGES variable send-email: avoid creating more than one Term::ReadLine object send-email: drop FakeTerm hack 24 May 2024, 23:57:43 UTC
4f215d2 Junio C Hamano 24 May 2024, 23:57:01 UTC Merge branch 'fixes/2.45.1/2.40' into fixes/2.45.1/2.41 * fixes/2.45.1/2.40: Revert "fsck: warn about symlink pointing inside a gitdir" Revert "Add a helper function to compare file contents" clone: drop the protections where hooks aren't run tests: verify that `clone -c core.hooksPath=/dev/null` works again Revert "core.hooksPath: add some protection while cloning" init: use the correct path of the templates directory again hook: plug a new memory leak ci: stop installing "gcc-13" for osx-gcc ci: avoid bare "gcc" for osx-gcc job ci: drop mention of BREW_INSTALL_PACKAGES variable send-email: avoid creating more than one Term::ReadLine object send-email: drop FakeTerm hack 24 May 2024, 23:57:02 UTC
48440f6 Junio C Hamano 24 May 2024, 19:29:35 UTC Merge branch 'jc/fix-2.45.1-and-friends-for-2.39' into fixes/2.45.1/2.40 Revert overly aggressive "layered defence" that went into 2.45.1 and friends, which broke "git-lfs", "git-annex", and other use cases, so that we can rebuild necessary counterparts in the open. * jc/fix-2.45.1-and-friends-for-2.39: Revert "fsck: warn about symlink pointing inside a gitdir" Revert "Add a helper function to compare file contents" clone: drop the protections where hooks aren't run tests: verify that `clone -c core.hooksPath=/dev/null` works again Revert "core.hooksPath: add some protection while cloning" init: use the correct path of the templates directory again hook: plug a new memory leak ci: stop installing "gcc-13" for osx-gcc ci: avoid bare "gcc" for osx-gcc job ci: drop mention of BREW_INSTALL_PACKAGES variable send-email: avoid creating more than one Term::ReadLine object send-email: drop FakeTerm hack 24 May 2024, 19:29:36 UTC
1991703 Junio C Hamano 23 May 2024, 04:55:31 UTC Revert "fsck: warn about symlink pointing inside a gitdir" This reverts commit a33fea08 (fsck: warn about symlink pointing inside a gitdir, 2024-04-10), which warns against symbolic links commonly created by git-annex. 23 May 2024, 04:55:31 UTC
35dfccb Johannes Schindelin 20 May 2024, 20:22:05 UTC Revert "Add a helper function to compare file contents" Now that during a `git clone`, the hooks' contents are no longer compared to the templates' files', the caller for which the `do_files_match()` function was introduced is gone, and therefore this function can be retired, too. This reverts commit 584de0b4c23 (Add a helper function to compare file contents, 2024-03-30). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 May 2024, 19:33:08 UTC
873a466 Johannes Schindelin 20 May 2024, 20:22:04 UTC clone: drop the protections where hooks aren't run As part of the security bug-fix releases v2.39.4, ..., v2.45.1, I introduced logic to safeguard `git clone` from running hooks that were installed _during_ the clone operation. The rationale was that Git's CVE-2024-32002, CVE-2021-21300, CVE-2019-1354, CVE-2019-1353, CVE-2019-1352, and CVE-2019-1349 should have been low-severity vulnerabilities but were elevated to critical/high severity by the attack vector that allows a weakness where files inside `.git/` can be inadvertently written during a `git clone` to escalate to a Remote Code Execution attack by virtue of installing a malicious `post-checkout` hook that Git will then run at the end of the operation without giving the user a chance to see what code is executed. Unfortunately, Git LFS uses a similar strategy to install its own `post-checkout` hook during a `git clone`; In fact, Git LFS is installing four separate hooks while running the `smudge` filter. While this pattern is probably in want of being improved by introducing better support in Git for Git LFS and other tools wishing to register hooks to be run at various stages of Git's commands, let's undo the clone protections to unbreak Git LFS-enabled clones. This reverts commit 8db1e8743c0 (clone: prevent hooks from running during a clone, 2024-03-28). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 May 2024, 19:33:08 UTC
c8f6478 Johannes Schindelin 20 May 2024, 20:22:03 UTC tests: verify that `clone -c core.hooksPath=/dev/null` works again As part of the protections added in Git v2.45.1 and friends, repository-local `core.hooksPath` settings are no longer allowed, as a defense-in-depth mechanism to prevent future Git vulnerabilities to raise to critical level if those vulnerabilities inadvertently allow the repository-local config to be written. What the added protection did not anticipate is that such a repository-local `core.hooksPath` can not only be used to point to maliciously-placed scripts in the current worktree, but also to _prevent_ hooks from being called altogether. We just reverted the `core.hooksPath` protections, based on the Git maintainer's recommendation in https://lore.kernel.org/git/xmqq4jaxvm8z.fsf@gitster.g/ to address this concern as well as related ones. Let's make sure that we won't regress while trying to protect the clone operation further. Reported-by: Brooke Kuhlmann <brooke@alchemists.io> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 May 2024, 19:33:08 UTC
75631a3 Johannes Schindelin 20 May 2024, 20:22:02 UTC Revert "core.hooksPath: add some protection while cloning" This defense-in-depth was intended to protect the clone operation against future escalations where bugs in `git clone` would allow attackers to write arbitrary files in the `.git/` directory would allow for Remote Code Execution attacks via maliciously-placed hooks. However, it turns out that the `core.hooksPath` protection has unintentional side effects so severe that they do not justify the benefit of the protections. For example, it has been reported in https://lore.kernel.org/git/FAFA34CB-9732-4A0A-87FB-BDB272E6AEE8@alchemists.io/ that the following invocation, which is intended to make `git clone` safer, is itself broken by that protective measure: git clone --config core.hooksPath=/dev/null <url> Since it turns out that the benefit does not justify the cost, let's revert 20f3588efc6 (core.hooksPath: add some protection while cloning, 2024-03-30). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 May 2024, 19:33:08 UTC
197a772 Johannes Schindelin 20 May 2024, 20:22:01 UTC init: use the correct path of the templates directory again In df93e407f06 (init: refactor the template directory discovery into its own function, 2024-03-29), I refactored the way the templates directory is discovered. The refactoring was faithful, but missed a reference in the `Makefile` where the `DEFAULT_GIT_TEMPLATE_DIR` constant is defined. As a consequence, Git v2.45.1 and friends will always use the hard-coded path `/usr/share/git-core/templates`. Let's fix that by defining the `DEFAULT_GIT_TEMPLATE_DIR` when building `setup.o`, where that constant is actually used. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 May 2024, 19:33:08 UTC
ee05253 Johannes Schindelin 20 May 2024, 20:22:00 UTC hook: plug a new memory leak In 8db1e8743c0 (clone: prevent hooks from running during a clone, 2024-03-28), I introduced an inadvertent memory leak that was unfortunately not caught before v2.45.1 was released. Here is a fix. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 May 2024, 19:33:08 UTC
d17d18f Jeff King 09 May 2024, 16:25:44 UTC ci: stop installing "gcc-13" for osx-gcc Our osx-gcc job explicitly asks to install gcc-13. But since the GitHub runner image already comes with gcc-13 installed, this is mostly doing nothing (or in some cases it may install an incremental update over the runner image). But worse, it recently started causing errors like: ==> Fetching gcc@13 ==> Downloading https://ghcr.io/v2/homebrew/core/gcc/13/blobs/sha256:fb2403d97e2ce67eb441b54557cfb61980830f3ba26d4c5a1fe5ecd0c9730d1a ==> Pouring gcc@13--13.2.0.ventura.bottle.tar.gz Error: The `brew link` step did not complete successfully The formula built, but is not symlinked into /usr/local Could not symlink bin/c++-13 Target /usr/local/bin/c++-13 is a symlink belonging to gcc. You can unlink it: brew unlink gcc which cause the whole CI job to bail. I didn't track down the root cause, but I suspect it may be related to homebrew recently switching the "gcc" default to gcc-14. And it may even be fixed when a new runner image is released. But if we don't need to run brew at all, it's one less thing for us to worry about. [jc: cherry-picked from v2.45.0-3-g7df2405b38] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 May 2024, 19:33:08 UTC
93ec0a7 Jeff King 09 May 2024, 16:24:15 UTC ci: avoid bare "gcc" for osx-gcc job On macOS, a bare "gcc" (without a version) will invoke a wrapper for clang, not actual gcc. Even when gcc is installed via homebrew, that only provides version-specific links in /usr/local/bin (like "gcc-13"), and never a version-agnostic "gcc" wrapper. As far as I can tell, this has been the case for a long time, and this osx-gcc job has largely been doing nothing. We can point it at "gcc-13", which will pick up the homebrew-installed version. The fix here is specific to the github workflow file, as the gitlab one does not have a matching job. It's a little unfortunate that we cannot just ask for the latest version of gcc which homebrew provides, but as far as I can tell there is no easy alias (you'd have to find the highest number gcc-* in /usr/local/bin yourself). [jc: cherry-picked from v2.45.0-2-g11c7001e3d] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 May 2024, 19:33:08 UTC
b6b9faf Jeff King 09 May 2024, 16:23:05 UTC ci: drop mention of BREW_INSTALL_PACKAGES variable The last user of this variable went away in 4a6e4b9602 (CI: remove Travis CI support, 2021-11-23), so it's doing nothing except making it more confusing to find out which packages _are_ installed. [jc: cherry-picked from v2.45.0-1-g9d4453e8d6] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 May 2024, 19:33:08 UTC
d11c51e Jeff King 08 August 2023, 18:15:31 UTC send-email: avoid creating more than one Term::ReadLine object Every time git-send-email calls its ask() function to prompt the user, we call term(), which instantiates a new Term::ReadLine object. But in v1.46 of Term::ReadLine::Gnu (which provides the Term::ReadLine interface on some platforms), its constructor refuses to create a second instance[1]. So on systems with that version of the module, most git-send-email instances will fail (as we usually prompt for both "to" and "in-reply-to" unless the user provided them on the command line). We can fix this by keeping a single instance variable and returning it for each call to term(). In perl 5.10 and up, we could do that with a "state" variable. But since we only require 5.008, we'll do it the old-fashioned way, with a lexical "my" in its own scope. Note that the tests in t9001 detect this problem as-is, since the failure mode is for the program to die. But let's also beef up the "Prompting works" test to check that it correctly handles multiple inputs (if we had chosen to keep our FakeTerm hack in the previous commit, then the failure mode would be incorrectly ignoring prompts after the first). [1] For discussion of why multiple instances are forbidden, see: https://github.com/hirooih/perl-trg/issues/16 [jc: cherry-picked from v2.42.0-rc2~6^2] Signed-off-by: Jeff King <peff@peff.net> Acked-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 May 2024, 19:33:07 UTC
fde2b4b Jeff King 08 August 2023, 18:14:36 UTC send-email: drop FakeTerm hack Back in 280242d1cc (send-email: do not barf when Term::ReadLine does not like your terminal, 2006-07-02), we added a fallback for when Term::ReadLine's constructor failed: we'd have a FakeTerm object instead, which would then die if anybody actually tried to call readline() on it. Since we instantiated the $term variable at program startup, we needed this workaround to let the program run in modes when we did not prompt the user. But later, in f4dc9432fd (send-email: lazily load modules for a big speedup, 2021-05-28), we started loading Term::ReadLine lazily only when ask() is called. So at that point we know we're trying to prompt the user, and we can just die if ReadLine instantiation fails, rather than making this fake object to lazily delay showing the error. This should be OK even if there is no tty (e.g., we're in a cron job), because Term::ReadLine will return a stub object in that case whose "IN" and "OUT" functions return undef. And since 5906f54e47 (send-email: don't attempt to prompt if tty is closed, 2009-03-31), we check for that case and skip prompting. And we can be sure that FakeTerm was not kicking in for such a situation, because it has actually been broken since that commit! It does not define "IN" or "OUT" methods, so perl would barf with an error. If FakeTerm was in use, we were neither honoring what 5906f54e47 tried to do, nor producing the readable message that 280242d1cc intended. So we're better off just dropping FakeTerm entirely, and letting the error reported by constructing Term::ReadLine through. [jc: cherry-picked from v2.42.0-rc2~6^2~1] Signed-off-by: Jeff King <peff@peff.net> Acked-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 May 2024, 19:33:07 UTC
babb4e5 Johannes Schindelin 10 April 2024, 19:51:47 UTC Git 2.42.2 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 19 April 2024, 10:38:48 UTC
be348e9 Johannes Schindelin 17 April 2024, 09:39:09 UTC Sync with 2.41.1 * maint-2.41: (38 commits) Git 2.41.1 Git 2.40.2 Git 2.39.4 fsck: warn about symlink pointing inside a gitdir core.hooksPath: add some protection while cloning init.templateDir: consider this config setting protected clone: prevent hooks from running during a clone Add a helper function to compare file contents init: refactor the template directory discovery into its own function find_hook(): refactor the `STRIP_EXTENSION` logic clone: when symbolic links collide with directories, keep the latter entry: report more colliding paths t5510: verify that D/F confusion cannot lead to an RCE submodule: require the submodule path to contain directories only clone_submodule: avoid using `access()` on directories submodules: submodule paths must not contain symlinks clone: prevent clashing git dirs when cloning submodule in parallel t7423: add tests for symlinked submodule directories has_dir_name(): do not get confused by characters < '/' docs: document security issues around untrusted .git dirs ... 19 April 2024, 10:38:46 UTC
0f15832 Johannes Schindelin 10 April 2024, 19:06:57 UTC Git 2.41.1 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 19 April 2024, 10:38:43 UTC
f5b2af0 Johannes Schindelin 17 April 2024, 09:38:18 UTC Sync with 2.40.2 * maint-2.40: (39 commits) Git 2.40.2 Git 2.39.4 fsck: warn about symlink pointing inside a gitdir core.hooksPath: add some protection while cloning init.templateDir: consider this config setting protected clone: prevent hooks from running during a clone Add a helper function to compare file contents init: refactor the template directory discovery into its own function find_hook(): refactor the `STRIP_EXTENSION` logic clone: when symbolic links collide with directories, keep the latter entry: report more colliding paths t5510: verify that D/F confusion cannot lead to an RCE submodule: require the submodule path to contain directories only clone_submodule: avoid using `access()` on directories submodules: submodule paths must not contain symlinks clone: prevent clashing git dirs when cloning submodule in parallel t7423: add tests for symlinked submodule directories has_dir_name(): do not get confused by characters < '/' docs: document security issues around untrusted .git dirs upload-pack: disable lazy-fetching by default ... 19 April 2024, 10:38:42 UTC
b9b439e Johannes Schindelin 10 April 2024, 18:56:02 UTC Git 2.40.2 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 19 April 2024, 10:38:38 UTC
93a88f4 Johannes Schindelin 12 April 2024, 07:45:28 UTC Sync with 2.39.4 * maint-2.39: (38 commits) Git 2.39.4 fsck: warn about symlink pointing inside a gitdir core.hooksPath: add some protection while cloning init.templateDir: consider this config setting protected clone: prevent hooks from running during a clone Add a helper function to compare file contents init: refactor the template directory discovery into its own function find_hook(): refactor the `STRIP_EXTENSION` logic clone: when symbolic links collide with directories, keep the latter entry: report more colliding paths t5510: verify that D/F confusion cannot lead to an RCE submodule: require the submodule path to contain directories only clone_submodule: avoid using `access()` on directories submodules: submodule paths must not contain symlinks clone: prevent clashing git dirs when cloning submodule in parallel t7423: add tests for symlinked submodule directories has_dir_name(): do not get confused by characters < '/' docs: document security issues around untrusted .git dirs upload-pack: disable lazy-fetching by default fetch/clone: detect dubious ownership of local repositories ... 19 April 2024, 10:38:37 UTC
47b6d90 Johannes Schindelin 10 April 2024, 18:37:40 UTC Git 2.39.4 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 19 April 2024, 10:38:33 UTC
9e65df5 Johannes Schindelin 12 April 2024, 22:28:19 UTC Merge branch 'ownership-checks-in-local-clones' This topic addresses two CVEs: - CVE-2024-32020: Local clones may end up hardlinking files into the target repository's object database when source and target repository reside on the same disk. If the source repository is owned by a different user, then those hardlinked files may be rewritten at any point in time by the untrusted user. - CVE-2024-32021: When cloning a local source repository that contains symlinks via the filesystem, Git may create hardlinks to arbitrary user-readable files on the same filesystem as the target repository in the objects/ directory. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 19 April 2024, 10:38:32 UTC
2b3d38a Johannes Schindelin 30 March 2024, 23:22:41 UTC Merge branch 'defense-in-depth' This topic branch adds a couple of measures designed to make it much harder to exploit any bugs in Git's recursive clone machinery that might be found in the future. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 19 April 2024, 10:38:29 UTC
a33fea0 Johannes Schindelin 10 April 2024, 16:01:13 UTC fsck: warn about symlink pointing inside a gitdir In the wake of fixing a vulnerability where `git clone` mistakenly followed a symbolic link that it had just written while checking out files, writing into a gitdir, let's add some defense-in-depth by teaching `git fsck` to report symbolic links stored in its trees that point inside `.git/`. Even though the Git project never made any promises about the exact shape of the `.git/` directory's contents, there are likely repositories out there containing symbolic links that point inside the gitdir. For that reason, let's only report these as warnings, not as errors. Security-conscious users are encouraged to configure `fsck.symlinkPointsToGitDir = error`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 19 April 2024, 10:38:25 UTC
20f3588 Johannes Schindelin 30 March 2024, 18:12:50 UTC core.hooksPath: add some protection while cloning Quite frequently, when vulnerabilities were found in Git's (quite complex) clone machinery, a relatively common way to escalate the severity was to trick Git into running a hook which is actually a script that has just been laid on disk as part of that clone. This constitutes a Remote Code Execution vulnerability, the highest severity observed in Git's vulnerabilities so far. Some previously-fixed vulnerabilities allowed malicious repositories to be crafted such that Git would check out files not in the worktree, but in, say, a submodule's `<git>/hooks/` directory. A vulnerability that "merely" allows to modify the Git config would allow a related attack vector, to manipulate Git into looking in the worktree for hooks, e.g. redirecting the location where Git looks for hooks, via setting `core.hooksPath` (which would be classified as CWE-427: Uncontrolled Search Path Element and CWE-114: Process Control, for more details see https://cwe.mitre.org/data/definitions/427.html and https://cwe.mitre.org/data/definitions/114.html). To prevent that attack vector, let's error out and complain loudly if an active `core.hooksPath` configuration is seen in the repository-local Git config during a `git clone`. There is one caveat: This changes Git's behavior in a slightly backwards-incompatible manner. While it is probably a rare scenario (if it exists at all) to configure `core.hooksPath` via a config in the Git templates, it _is_ conceivable that some valid setup requires this to work. In the hopefully very unlikely case that a user runs into this, there is an escape hatch: set the `GIT_CLONE_PROTECTION_ACTIVE=false` environment variable. Obviously, this should be done only with utmost caution. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 19 April 2024, 10:38:24 UTC
4412a04 Johannes Schindelin 29 March 2024, 12:15:32 UTC init.templateDir: consider this config setting protected The ability to configuring the template directory is a delicate feature: It allows defining hooks that will be run e.g. during a `git clone` operation, such as the `post-checkout` hook. As such, it is of utmost importance that Git would not allow that config setting to be changed during a `git clone` by mistake, allowing an attacker a chance for a Remote Code Execution, allowing attackers to run arbitrary code on unsuspecting users' machines. As a defense-in-depth measure, to prevent minor vulnerabilities in the `git clone` code from ballooning into higher-serverity attack vectors, let's make this a protected setting just like `safe.directory` and friends, i.e. ignore any `init.templateDir` entries from any local config. Note: This does not change the behavior of any recursive clone (modulo bugs), as the local repository config is not even supposed to be written while cloning the superproject, except in one scenario: If a config template is configured that sets the template directory. This might be done because `git clone --recurse-submodules --template=<directory>` does not pass that template directory on to the submodules' initialization. Another scenario where this commit changes behavior is where repositories are _not_ cloned recursively, and then some (intentional, benign) automation configures the template directory to be used before initializing the submodules. So the caveat is that this could theoretically break existing processes. In both scenarios, there is a way out, though: configuring the template directory via the environment variable `GIT_TEMPLATE_DIR`. This change in behavior is a trade-off between security and backwards-compatibility that is struck in favor of security. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 19 April 2024, 10:38:24 UTC
8db1e87 Johannes Schindelin 28 March 2024, 18:21:06 UTC clone: prevent hooks from running during a clone Critical security issues typically combine relatively common vulnerabilities such as case confusion in file paths with other weaknesses in order to raise the severity of the attack. One such weakness that has haunted the Git project in many a submodule-related CVE is that any hooks that are found are executed during a clone operation. Examples are the `post-checkout` and `fsmonitor` hooks. However, Git's design calls for hooks to be disabled by default, as only disabled example hooks are copied over from the templates in `<prefix>/share/git-core/templates/`. As a defense-in-depth measure, let's prevent those hooks from running. Obviously, administrators can choose to drop enabled hooks into the template directory, though, _and_ it is also possible to override `core.hooksPath`, in which case the new check needs to be disabled. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 19 April 2024, 10:38:23 UTC
584de0b Johannes Schindelin 30 March 2024, 14:59:20 UTC Add a helper function to compare file contents In the next commit, Git will learn to disallow hooks during `git clone` operations _except_ when those hooks come from the templates (which are inherently supposed to be trusted). To that end, we add a function to compare the contents of two files. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 19 April 2024, 10:38:19 UTC
86cb6a3 Johannes Schindelin 30 March 2024, 23:22:41 UTC Merge branch 'icasefs-symlink-confusion' This topic branch fixes two vulnerabilities: - Recursive clones on case-insensitive filesystems that support symbolic links are susceptible to case confusion that can be exploited to execute just-cloned code during the clone operation. - Repositories can be configured to execute arbitrary code during local clones. To address this, the ownership checks introduced in v2.30.3 are now extended to cover cloning local repositories. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 April 2024, 20:30:24 UTC
df93e40 Johannes Schindelin 29 March 2024, 10:45:01 UTC init: refactor the template directory discovery into its own function We will need to call this function from `hook.c` to be able to prevent hooks from running that were written as part of a `clone` but did not originate from the template directory. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 April 2024, 20:30:10 UTC
48c171d Johannes Schindelin 28 March 2024, 18:02:30 UTC find_hook(): refactor the `STRIP_EXTENSION` logic When looking for a hook and not finding one, and when `STRIP_EXTENSION` is available (read: if we're on Windows and `.exe` is the required extension for executable programs), we want to look also for a hook with that extension. Previously, we added that handling into the conditional block that was meant to handle when no hook was found (possibly providing some advice for the user's benefit). If the hook with that file extension was found, we'd return early from that function instead of writing out said advice, of course. However, we're about to introduce a safety valve to prevent hooks from being run during a clone, to reduce the attack surface of bugs that allow writing files to be written into arbitrary locations. To prepare for that, refactor the logic to avoid the early return, by separating the `STRIP_EXTENSION` handling from the conditional block handling the case when no hook was found. This commit is best viewed with `--patience`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 April 2024, 20:30:09 UTC
31572dc Johannes Schindelin 28 March 2024, 09:55:07 UTC clone: when symbolic links collide with directories, keep the latter When recursively cloning a repository with submodules, we must ensure that the submodules paths do not suddenly contain symbolic links that would let Git write into unintended locations. We just plugged that vulnerability, but let's add some more defense-in-depth. Since we can only keep one item on disk if multiple index entries' paths collide, we may just as well avoid keeping a symbolic link (because that would allow attack vectors where Git follows those links by mistake). Technically, we handle more situations than cloning submodules into paths that were (partially) replaced by symbolic links. This provides defense-in-depth in case someone finds a case-folding confusion vulnerability in the future that does not even involve submodules. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 April 2024, 20:30:08 UTC
850c3a2 Johannes Schindelin 28 March 2024, 08:44:28 UTC entry: report more colliding paths In b878579ae7 (clone: report duplicate entries on case-insensitive filesystems, 2018-08-17) code was added to warn about index entries that resolve to the same file system entity (usually the cause is a case-insensitive filesystem). In Git for Windows, where inodes are not trusted (because of a performance trade-off, inodes are equal to 0 by default), that check does not compare inode numbers but the verbatim path. This logic works well when index entries' paths differ only in case. However, for file/directory conflicts only the file's path was reported, leaving the user puzzled with what that path collides. Let's try ot catch colliding paths even if one path is the prefix of the other. We do this also in setups where the file system is case-sensitive because the inode check would not be able to catch those collisions. While not a complete solution (for example, on macOS, Unicode normalization could also lead to file/directory conflicts but be missed by this logic), it is at least another defensive layer on top of what the previous commits added. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 April 2024, 20:30:07 UTC
e4930e8 Johannes Schindelin 24 March 2024, 13:13:41 UTC t5510: verify that D/F confusion cannot lead to an RCE The most critical vulnerabilities in Git lead to a Remote Code Execution ("RCE"), i.e. the ability for an attacker to have malicious code being run as part of a Git operation that is not expected to run said code, such has hooks delivered as part of a `git clone`. A couple of parent commits ago, a bug was fixed that let Git be confused by the presence of a path `a-` to mistakenly assume that a directory `a/` can safely be created without removing an existing `a` that is a symbolic link. This bug did not represent an exploitable vulnerability on its own; Let's make sure it stays that way. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 April 2024, 20:30:06 UTC
e8d0608 Johannes Schindelin 26 March 2024, 13:37:25 UTC submodule: require the submodule path to contain directories only Submodules are stored in subdirectories of their superproject. When these subdirectories have been replaced with symlinks by a malicious actor, all kinds of mayhem can be caused. This _should_ not be possible, but many CVEs in the past showed that _when_ possible, it allows attackers to slip in code that gets executed during, say, a `git clone --recursive` operation. Let's add some defense-in-depth to disallow submodule paths to have anything except directories in them. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 April 2024, 20:30:04 UTC
eafffd9 Johannes Schindelin 12 April 2024, 19:00:44 UTC clone_submodule: avoid using `access()` on directories In 0060fd1511b (clone --recurse-submodules: prevent name squatting on Windows, 2019-09-12), I introduced code to verify that a git dir either does not exist, or is at least empty, to fend off attacks where an inadvertently (and likely maliciously) pre-populated git dir would be used while cloning submodules recursively. The logic used `access(<path>, X_OK)` to verify that a directory exists before calling `is_empty_dir()` on it. That is a curious way to check for a directory's existence and might well fail for unwanted reasons. Even the original author (it was I ;-) ) struggles to explain why this function was used rather than `stat()`. This code was _almost_ copypastad in the previous commit, but that `access()` call was caught during review. Let's use `stat()` instead also in the code that was almost copied verbatim. Let's not use `lstat()` because in the unlikely event that somebody snuck a symbolic link in, pointing to a crafted directory, we want to verify that that directory is empty. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 April 2024, 20:30:03 UTC
9706576 Johannes Schindelin 22 March 2024, 10:19:22 UTC submodules: submodule paths must not contain symlinks When creating a submodule path, we must be careful not to follow symbolic links. Otherwise we may follow a symbolic link pointing to a gitdir (which are valid symbolic links!) e.g. while cloning. On case-insensitive filesystems, however, we blindly replace a directory that has been created as part of the `clone` operation with a symlink when the path to the latter differs only in case from the former's path. Let's simply avoid this situation by expecting not ever having to overwrite any existing file/directory/symlink upon cloning. That way, we won't even replace a directory that we just created. This addresses CVE-2024-32002. Reported-by: Filip Hejsek <filip.hejsek@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 April 2024, 20:30:02 UTC
9cf8547 Filip Hejsek 28 January 2024, 04:09:17 UTC clone: prevent clashing git dirs when cloning submodule in parallel While it is expected to have several git dirs within the `.git/modules/` tree, it is important that they do not interfere with each other. For example, if one submodule was called "captain" and another submodule "captain/hooks", their respective git dirs would clash, as they would be located in `.git/modules/captain/` and `.git/modules/captain/hooks/`, respectively, i.e. the latter's files could clash with the actual Git hooks of the former. To prevent these clashes, and in particular to prevent hooks from being written and then executed as part of a recursive clone, we introduced checks as part of the fix for CVE-2019-1387 in a8dee3ca61 (Disallow dubiously-nested submodule git directories, 2019-10-01). It is currently possible to bypass the check for clashing submodule git dirs in two ways: 1. parallel cloning 2. checkout --recurse-submodules Let's check not only before, but also after parallel cloning (and before checking out the submodule), that the git dir is not clashing with another one, otherwise fail. This addresses the parallel cloning issue. As to the parallel checkout issue: It requires quite a few manual steps to create clashing git dirs because Git itself would refuse to initialize the inner one, as demonstrated by the test case. Nevertheless, let's teach the recursive checkout (namely, the `submodule_move_head()` function that is used by the recursive checkout) to be careful to verify that it does not use a clashing git dir, and if it does, disable it (by deleting the `HEAD` file so that subsequent Git calls won't recognize it as a git dir anymore). Note: The parallel cloning test case contains a `cat err` that proved to be highly useful when analyzing the racy nature of the operation (the operation can fail with three different error messages, depending on timing), and was left on purpose to ease future debugging should the need arise. Signed-off-by: Filip Hejsek <filip.hejsek@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 April 2024, 20:30:01 UTC
b20c10f Filip Hejsek 28 January 2024, 03:32:47 UTC t7423: add tests for symlinked submodule directories Submodule operations must not follow symlinks in working tree, because otherwise files might be written to unintended places, leading to vulnerabilities. Signed-off-by: Filip Hejsek <filip.hejsek@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 April 2024, 20:30:00 UTC
c30a574 Filip Hejsek 28 January 2024, 03:30:25 UTC has_dir_name(): do not get confused by characters < '/' There is a bug in directory/file ("D/F") conflict checking optimization: It assumes that such a conflict cannot happen if a newly added entry's path is lexicgraphically "greater than" the last already-existing index entry _and_ contains a directory separator that comes strictly after the common prefix (`len > len_eq_offset`). This assumption is incorrect, though: `a-` sorts _between_ `a` and `a/b`, their common prefix is `a`, the slash comes after the common prefix, and there is still a file/directory conflict. Let's re-design this logic, taking these facts into consideration: - It is impossible for a file to sort after another file with whose directory it conflicts because the trailing NUL byte is always smaller than any other character. - Since there are quite a number of ASCII characters that sort before the slash (e.g. `-`, `.`, the space character), looking at the last already-existing index entry is not enough to determine whether there is a D/F conflict when the first character different from the existing last index entry's path is a slash. If it is not a slash, there cannot be a file/directory conflict. And if the existing index entry's first different character is a slash, it also cannot be a file/directory conflict because the optimization requires the newly-added entry's path to sort _after_ the existing entry's, and the conflicting file's path would not. So let's fall back to the regular binary search whenever the newly-added item's path differs in a slash character. If it does not, and it sorts after the last index entry, there is no D/F conflict and the new index entry can be safely appended. This fix also nicely simplifies the logic and makes it much easier to reason about, while the impact on performance should be negligible: After this fix, the optimization will be skipped only when index entry's paths differ in a slash and a space, `!`, `"`, `#`, `$`, `%`, `&`, `'`, | ( `)`, `*`, `+`, `,`, `-`, or `.`, which should be a rare situation. Signed-off-by: Filip Hejsek <filip.hejsek@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 April 2024, 20:29:58 UTC
e69ac42 Jeff King 16 April 2024, 08:52:13 UTC docs: document security issues around untrusted .git dirs For a long time our general philosophy has been that it's unsafe to run arbitrary Git commands if you don't trust the hooks or config in .git, but that running upload-pack should be OK. E.g., see 1456b043fc (Remove post-upload-hook, 2009-12-10), or the design of uploadpack.packObjectsHook. But we never really documented this (and even the discussions that led to 1456b043fc were not on the public list!). Let's try to make our approach more clear, but also be realistic that even upload-pack carries some risk. Helped-by: Filip Hejsek <filip.hejsek@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 April 2024, 20:29:57 UTC
7b70e9e Jeff King 16 April 2024, 08:35:33 UTC upload-pack: disable lazy-fetching by default The upload-pack command tries to avoid trusting the repository in which it's run (e.g., by not running any hooks and not using any config that contains arbitrary commands). But if the server side of a fetch or a clone is a partial clone, then either upload-pack or its child pack-objects may run a lazy "git fetch" under the hood. And it is very easy to convince fetch to run arbitrary commands. The "server" side can be a local repository owned by someone else, who would be able to configure commands that are run during a clone with the current user's permissions. This issue has been designated CVE-2024-32004. The fix in this commit's parent helps in this scenario, as well as in related scenarios using SSH to clone, where the untrusted .git directory is owned by a different user id. But if you received one as a zip file, on a USB stick, etc, it may be owned by your user but still untrusted. This has been designated CVE-2024-32465. To mitigate the issue more completely, let's disable lazy fetching entirely during `upload-pack`. While fetching from a partial repository should be relatively rare, it is certainly not an unreasonable workflow. And thus we need to provide an escape hatch. This commit works by respecting a GIT_NO_LAZY_FETCH environment variable (to skip the lazy-fetch), and setting it in upload-pack, but only when the user has not already done so (which gives us the escape hatch). The name of the variable is specifically chosen to match what has already been added in 'master' via e6d5479e7a (git: extend --no-lazy-fetch to work across subprocesses, 2024-02-27). Since we're building this fix as a backport for older versions, we could cherry-pick that patch and its earlier steps. However, we don't really need the niceties (like a "--no-lazy-fetch" option) that it offers. By using the same name, everything should just work when the two are eventually merged, but here are a few notes: - the blocking of the fetch in e6d5479e7a is incomplete! It sets fetch_if_missing to 0 when we setup the repository variable, but that isn't enough. pack-objects in particular will call prefetch_to_pack() even if that variable is 0. This patch by contrast checks the environment variable at the lowest level before we call the lazy fetch, where we can be sure to catch all code paths. Possibly the setting of fetch_if_missing from e6d5479e7a can be reverted, but it may be useful to have. For example, some code may want to use that flag to change behavior before it gets to the point of trying to start the fetch. At any rate, that's all outside the scope of this patch. - there's documentation for GIT_NO_LAZY_FETCH in e6d5479e7a. We can live without that here, because for the most part the user shouldn't need to set it themselves. The exception is if they do want to override upload-pack's default, and that requires a separate documentation section (which is added here) - it would be nice to use the NO_LAZY_FETCH_ENVIRONMENT macro added by e6d5479e7a, but those definitions have moved from cache.h to environment.h between 2.39.3 and master. I just used the raw string literals, and we can replace them with the macro once this topic is merged to master. At least with respect to CVE-2024-32004, this does render this commit's parent commit somewhat redundant. However, it is worth retaining that commit as defense in depth, and because it may help other issues (e.g., symlink/hardlink TOCTOU races, where zip files are not really an interesting attack vector). The tests in t0411 still pass, but now we have _two_ mechanisms ensuring that the evil command is not run. Let's beef up the existing ones to check that they failed for the expected reason, that we refused to run upload-pack at all with an alternate user id. And add two new ones for the same-user case that both the restriction and its escape hatch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 April 2024, 20:29:56 UTC
f4aa8c8 Johannes Schindelin 10 April 2024, 12:39:37 UTC fetch/clone: detect dubious ownership of local repositories When cloning from somebody else's repositories, it is possible that, say, the `upload-pack` command is overridden in the repository that is about to be cloned, which would then be run in the user's context who started the clone. To remind the user that this is a potentially unsafe operation, let's extend the ownership checks we have already established for regular gitdir discovery to extend also to local repositories that are about to be cloned. This protection extends also to file:// URLs. The fixes in this commit address CVE-2024-32004. Note: This commit does not touch the `fetch`/`clone` code directly, but instead the function used implicitly by both: `enter_repo()`. This function is also used by `git receive-pack` (i.e. pushes), by `git upload-archive`, by `git daemon` and by `git http-backend`. In setups that want to serve repositories owned by different users than the account running the service, this will require `safe.*` settings to be configured accordingly. Also note: there are tiny time windows where a time-of-check-time-of-use ("TOCTOU") race is possible. The real solution to those would be to work with `fstat()` and `openat()`. However, the latter function is not available on Windows (and would have to be emulated with rather expensive low-level `NtCreateFile()` calls), and the changes would be quite extensive, for my taste too extensive for the little gain given that embargoed releases need to pay extra attention to avoid introducing inadvertent bugs. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 April 2024, 20:29:54 UTC
5c5a4a1 Filip Hejsek 28 January 2024, 03:29:33 UTC t0411: add tests for cloning from partial repo Cloning from a partial repository must not fetch missing objects into the partial repository, because that can lead to arbitrary code execution. Add a couple of test cases, pretending to the `upload-pack` command (and to that command only) that it is working on a repository owned by someone else. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Filip Hejsek <filip.hejsek@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 April 2024, 20:29:53 UTC
1204e1a Patrick Steinhardt 15 April 2024, 11:30:41 UTC builtin/clone: refuse local clones of unsafe repositories When performing a local clone of a repository we end up either copying or hardlinking the source repository into the target repository. This is significantly more performant than if we were to use git-upload-pack(1) and git-fetch-pack(1) to create the new repository and preserves both disk space and compute time. Unfortunately though, performing such a local clone of a repository that is not owned by the current user is inherently unsafe: - It is possible that source files get swapped out underneath us while we are copying or hardlinking them. While we do perform some checks here to assert that we hardlinked the expected file, they cannot reliably thwart time-of-check-time-of-use (TOCTOU) style races. It is thus possible for an adversary to make us copy or hardlink unexpected files into the target directory. Ideally, we would address this by starting to use openat(3P), fstatat(3P) and friends. Due to platform compatibility with Windows we cannot easily do that though. Furthermore, the scope of these fixes would likely be quite broad and thus not fit for an embargoed security release. - Even if we handled TOCTOU-style races perfectly, hardlinking files owned by a different user into the target repository is not a good idea in general. It is possible for an adversary to rewrite those files to contain whatever data they want even after the clone has completed. Address these issues by completely refusing local clones of a repository that is not owned by the current user. This reuses our existing infra we have in place via `ensure_valid_ownership()` and thus allows a user to override the safety guard by adding the source repository path to the "safe.directory" configuration. This addresses CVE-2024-32020. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 April 2024, 00:17:40 UTC
8c9c051 Patrick Steinhardt 15 April 2024, 11:30:36 UTC setup.c: introduce `die_upon_dubious_ownership()` Introduce a new function `die_upon_dubious_ownership()` that uses `ensure_valid_ownership()` to verify whether a repositroy is safe for use, and causes Git to die in case it is not. This function will be used in a subsequent commit. Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 16 April 2024, 22:01:26 UTC
d1bb66a Patrick Steinhardt 15 April 2024, 11:30:31 UTC builtin/clone: abort when hardlinked source and target file differ When performing local clones with hardlinks we refuse to copy source files which are symlinks as a mitigation for CVE-2022-39253. This check can be raced by an adversary though by changing the file to a symlink after we have checked it. Fix the issue by checking whether the hardlinked destination file matches the source file and abort in case it doesn't. This addresses CVE-2024-32021. Reported-by: Apple Product Security <product-security@apple.com> Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 16 April 2024, 22:01:25 UTC
150e6b0 Patrick Steinhardt 15 April 2024, 11:30:26 UTC builtin/clone: stop resolving symlinks when copying files When a user performs a local clone without `--no-local`, then we end up copying the source repository into the target repository directly. To optimize this even further, we try to hardlink files into place instead of copying data over, which helps both disk usage and speed. There is an important edge case in this context though, namely when we try to hardlink symlinks from the source repository into the target repository. Depending on both platform and filesystem the resulting behaviour here can be different: - On macOS and NetBSD, calling link(3P) with a symlink target creates a hardlink to the file pointed to by the symlink. - On Linux, calling link(3P) instead creates a hardlink to the symlink itself. To unify this behaviour, 36596fd2df (clone: better handle symlinked files at .git/objects/, 2019-07-10) introduced logic to resolve symlinks before we try to link(3P) files. Consequently, the new behaviour was to always create a hard link to the target of the symlink on all platforms. Eventually though, we figured out that following symlinks like this can cause havoc when performing a local clone of a malicious repository, which resulted in CVE-2022-39253. This issue was fixed via 6f054f9fb3 (builtin/clone.c: disallow `--local` clones with symlinks, 2022-07-28), by refusing symlinks in the source repository. But even though we now shouldn't ever link symlinks anymore, the code that resolves symlinks still exists. In the best case the code does not end up doing anything because there are no symlinks anymore. In the worst case though this can be abused by an adversary that rewrites the source file after it has been checked not to be a symlink such that it actually is a symlink when we call link(3P). Thus, it is still possible to recreate CVE-2022-39253 due to this time-of-check-time-of-use bug. Remove the call to `realpath()`. This doesn't yet address the actual vulnerability, which will be handled in a subsequent commit. Reported-by: Apple Product Security <product-security@apple.com> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 16 April 2024, 22:01:25 UTC
9e06401 Johannes Schindelin 10 April 2024, 17:25:03 UTC Merge branch 'js/github-actions-update' Update remaining GitHub Actions jobs to avoid warnings against using deprecated version of Node.js. * js/github-actions-update: ci(linux32): add a note about Actions that must not be updated ci: bump remaining outdated Actions versions With this backport, `maint-2.39`'s CI builds are finally healthy again. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> 16 April 2024, 22:01:11 UTC
64f35ba Johannes Schindelin 10 April 2024, 17:25:03 UTC Merge branch 'jc/maint-github-actions-update' * jc/maint-github-actions-update: GitHub Actions: update to github-script@v7 GitHub Actions: update to checkout@v4 Yet another thing to help `maint-2.39`'s CI builds to become healthy again. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> 16 April 2024, 22:01:00 UTC
213958f Johannes Schindelin 11 February 2024, 12:11:29 UTC ci(linux32): add a note about Actions that must not be updated The Docker container used by the `linux32` job comes without Node.js, and therefore the `actions/checkout` and `actions/upload-artifact` Actions cannot be upgraded to the latest versions (because they use Node.js). One time too many, I accidentally tried to update them, where `actions/checkout` at least fails immediately, but the `actions/upload-artifact` step is only used when any test fails, and therefore the CI run usually passes even though that Action was updated to a version that is incompatible with the Docker container in which this job runs. So let's add a big fat warning, mainly for my own benefit, to avoid running into the very same issue over and over again. Backported-from: 20e0ff8835 (ci(linux32): add a note about Actions that must not be updated, 2024-02-11) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 16 April 2024, 22:00:58 UTC
7e1bcc8 Johannes Schindelin 11 February 2024, 12:11:28 UTC ci: bump remaining outdated Actions versions After activating automatic Dependabot updates in the git-for-windows/git repository, Dependabot noticed a couple of yet-unaddressed updates. They avoid "Node.js 16 Actions" deprecation messages by bumping the following Actions' versions: - actions/upload-artifact from 3 to 4 - actions/download-artifact from 3 to 4 - actions/cache from 3 to 4 Backported-from: 820a340085 (ci: bump remaining outdated Actions versions, 2024-02-11) Helped-by: Matthias Aßhauer <mha1993@live.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 16 April 2024, 22:00:57 UTC
f6bed64 Junio C Hamano 02 February 2024, 20:39:35 UTC GitHub Actions: update to github-script@v7 We seem to be getting "Node.js 16 actions are deprecated." warnings for jobs that use github-script@v6. Update to github-script@v7, which is said to use Node.js 20. Backported-from: c4ddbe043e (GitHub Actions: update to github-script@v7, 2024-02-02) Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 16 April 2024, 22:00:57 UTC
ce47f7c Junio C Hamano 02 February 2024, 20:39:34 UTC GitHub Actions: update to checkout@v4 We seem to be getting "Node.js 16 actions are deprecated." warnings for jobs that use checkout@v3. Except for the i686 containers job that is kept at checkout@v1 [*], update to checkout@v4, which is said to use Node.js 20. [*] 6cf4d908 (ci(main): upgrade actions/checkout to v3, 2022-12-05) refers to https://github.com/actions/runner/issues/2115 and explains why container jobs are kept at checkout@v1. We may want to check the current status of the issue and move it to the same version as other jobs, but that is outside the scope of this step. Backported-from: e94dec0c1d (GitHub Actions: update to checkout@v4, 2024-02-02) Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 16 April 2024, 22:00:57 UTC
6133e3a Johannes Schindelin 12 April 2024, 22:05:36 UTC Merge branch 'quicker-asan-lsan' This patch speeds up the `asan`/`lsan` jobs that are really slow enough already. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 16 April 2024, 22:00:56 UTC
ea094ee Johannes Schindelin 15 April 2024, 16:04:10 UTC Merge branch 'jk/test-lsan-denoise-output' Tests with LSan from time to time seem to emit harmless message that makes our tests unnecessarily flakey; we work it around by filtering the uninteresting output. * jk/test-lsan-denoise-output: test-lib: ignore uninteresting LSan output Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 16 April 2024, 22:00:54 UTC
b12dcab Johannes Schindelin 10 April 2024, 17:25:02 UTC Merge branch 'js/ci-use-macos-13' Replace macos-12 used at GitHub CI with macos-13. * js/ci-use-macos-13: ci: upgrade to using macos-13 This is another backport to `maint-2.39` to allow less CI jobs to break. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> 16 April 2024, 21:59:03 UTC
c7db432 Johannes Schindelin 10 April 2024, 17:25:02 UTC Merge branch 'backport/jk/libcurl-8.7-regression-workaround' into maint-2.39 Fix was added to work around a regression in libcURL 8.7.0 (which has already been fixed in their tip of the tree). * jk/libcurl-8.7-regression-workaround: remote-curl: add Transfer-Encoding header only for older curl INSTALL: bump libcurl version to 7.21.3 http: reset POSTFIELDSIZE when clearing curl handle Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> 16 April 2024, 21:58:53 UTC
e1813a3 Johannes Schindelin 28 March 2024, 08:25:36 UTC Merge branch 'jk/redact-h2h3-headers-fix' into maint-2.42 HTTP Header redaction code has been adjusted for a newer version of cURL library that shows its traces differently from earlier versions. * jk/redact-h2h3-headers-fix: http: update curl http/2 info matching for curl 8.3.0 http: factor out matching of curl http/2 trace lines This backport to `maint-2.39` is needed to bring the following test cases back to a working state in conjunction with recent libcurl versions: - t5559.17 GIT_TRACE_CURL redacts auth details - t5559.18 GIT_CURL_VERBOSE redacts auth details - t5559.38 cookies are redacted by default Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> 16 April 2024, 21:58:48 UTC
ef0fc42 Johannes Schindelin 27 March 2024, 15:59:42 UTC Merge branch 'jk/httpd-test-updates' Test update. * jk/httpd-test-updates: t/lib-httpd: increase ssl key size to 2048 bits t/lib-httpd: drop SSLMutex config t/lib-httpd: bump required apache version to 2.4 t/lib-httpd: bump required apache version to 2.2 This is a backport onto the `maint-2.39` branch, to improve the CI health of that branch. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> 16 April 2024, 21:58:40 UTC
e3cbeb9 Johannes Schindelin 27 March 2024, 15:59:19 UTC Merge branch 'jk/http-test-fixes' Various fix-ups on HTTP tests. * jk/http-test-fixes: t5559: make SSL/TLS the default t5559: fix test failures with LIB_HTTPD_SSL t/lib-httpd: enable HTTP/2 "h2" protocol, not just h2c t/lib-httpd: respect $HTTPD_PROTO in expect_askpass() t5551: drop curl trace lines without headers t5551: handle v2 protocol in cookie test t5551: simplify expected cookie file t5551: handle v2 protocol in upload-pack service test t5551: handle v2 protocol when checking curl trace t5551: stop forcing clone to run with v0 protocol t5551: handle HTTP/2 when checking curl trace t5551: lower-case headers in expected curl trace t5551: drop redundant grep for Accept-Language t5541: simplify and move "no empty path components" test t5541: stop marking "used receive-pack service" test as v0 only t5541: run "used receive-pack service" test earlier This is a backport onto the `maint-2.39` branch, starting to take care of making that branch's CI builds healthy again. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> 16 April 2024, 21:58:06 UTC
c67cf4c Jeff King 28 August 2023, 18:37:35 UTC test-lib: ignore uninteresting LSan output When I run the tests in leak-checking mode the same way our CI job does, like: make SANITIZE=leak \ GIT_TEST_PASSING_SANITIZE_LEAK=true \ GIT_TEST_SANITIZE_LEAK_LOG=true \ test then LSan can racily produce useless entries in the log files that look like this: ==git==3034393==Unable to get registers from thread 3034307. I think they're mostly harmless based on the source here: https://github.com/llvm/llvm-project/blob/7e0a52e8e9ef6394bb62e0b56e17fa23e7262411/compiler-rt/lib/lsan/lsan_common.cpp#L414 which reads: PtraceRegistersStatus have_registers = suspended_threads.GetRegistersAndSP(i, &registers, &sp); if (have_registers != REGISTERS_AVAILABLE) { Report("Unable to get registers from thread %llu.\n", os_id); // If unable to get SP, consider the entire stack to be reachable unless // GetRegistersAndSP failed with ESRCH. if (have_registers == REGISTERS_UNAVAILABLE_FATAL) continue; sp = stack_begin; } The program itself still runs fine and LSan doesn't cause us to abort. But test-lib.sh looks for any non-empty LSan logs and marks the test as a failure anyway, under the assumption that we simply missed the failing exit code somehow. I don't think I've ever seen this happen in the CI job, but running locally using clang-14 on an 8-core machine, I can't seem to make it through a full run of the test suite without having at least one failure. And it's a different one every time (though they do seem to often be related to packing tests, which makes sense, since that is one of our biggest users of threaded code). We can hack around this by only counting LSan log files that contain a line that doesn't match our known-uninteresting pattern. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 16 April 2024, 21:58:04 UTC
cf5dcd8 Johannes Schindelin 27 March 2024, 15:28:18 UTC ci(linux-asan/linux-ubsan): let's save some time Every once in a while, the `git-p4` tests flake for reasons outside of our control. It typically fails with "Connection refused" e.g. here: https://github.com/git/git/actions/runs/5969707156/job/16196057724 [...] + git p4 clone --dest=/home/runner/work/git/git/t/trash directory.t9807-git-p4-submit/git //depot Initialized empty Git repository in /home/runner/work/git/git/t/trash directory.t9807-git-p4-submit/git/.git/ Perforce client error: Connect to server failed; check $P4PORT. TCP connect to localhost:9807 failed. connect: 127.0.0.1:9807: Connection refused failure accessing depot: could not run p4 Importing from //depot into /home/runner/work/git/git/t/trash directory.t9807-git-p4-submit/git [...] This happens in other jobs, too, but in the `linux-asan`/`linux-ubsan` jobs it hurts the most because those jobs often take an _awfully_ long time to run, therefore re-running a failed `linux-asan`/`linux-ubsan` jobs is _very_ costly. The purpose of the `linux-asan`/`linux-ubsan` jobs is to exercise the C code of Git, anyway, and any part of Git's source code that the `git-p4` tests run and that would benefit from the attention of ASAN/UBSAN are run better in other tests anyway, as debugging C code run via Python scripts can get a bit hairy. In fact, it is not even just `git-p4` that is the problem (even if it flakes often enough to be problematic in the CI builds), but really the part about Python scripts. So let's just skip any Python parts of the tests from being run in that job. For good measure, also skip the Subversion tests because debugging C code run via Perl scripts is as much fun as debugging C code run via Python scripts. And it will reduce the time this very expensive job takes, which is a big benefit. Backported to `maint-2.39` as another step to get that branch's CI builds back to a healthy state. Backported-from: 6ba913629f (ci(linux-asan-ubsan): let's save some time, 2023-08-29) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 16 April 2024, 21:58:04 UTC
3167b60 Johannes Schindelin 03 November 2023, 07:27:35 UTC ci: upgrade to using macos-13 In April, GitHub announced that the `macos-13` pool is available: https://github.blog/changelog/2023-04-24-github-actions-macos-13-is-now-available/. It is only a matter of time until the `macos-12` pool is going away, therefore we should switch now, without pressure of a looming deadline. Since the `macos-13` runners no longer include Python2, we also drop specifically testing with Python2 and switch uniformly to Python3, see https://github.com/actions/runner-images/blob/HEAD/images/macos/macos-13-Readme.md for details about the software available on the `macos-13` pool's runners. Also, on macOS 13, Homebrew seems to install a `gcc@9` package that no longer comes with a regular `unistd.h` (there seems only to be a `ssp/unistd.h`), and hence builds would fail with: In file included from base85.c:1: git-compat-util.h:223:10: fatal error: unistd.h: No such file or directory 223 | #include <unistd.h> | ^~~~~~~~~~ compilation terminated. The reason why we install GCC v9.x explicitly is historical, and back in the days it was because it was the _newest_ version available via Homebrew: 176441bfb58 (ci: build Git with GCC 9 in the 'osx-gcc' build job, 2019-11-27). To reinstate the spirit of that commit _and_ to fix that build failure, let's switch to the now-newest GCC version: v13.x. Backported-from: 682a868f67 (ci: upgrade to using macos-13, 2023-11-03) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 16 April 2024, 21:58:03 UTC
bddc176 Johannes Schindelin 27 March 2024, 16:04:43 UTC Merge branch 'jh/fsmonitor-darwin-modernize' Stop using deprecated macOS API in fsmonitor. * jh/fsmonitor-darwin-modernize: fsmonitor: eliminate call to deprecated FSEventStream function This backport to `maint-2.39` is needed to be able to build on `macos-13`, which we need to update to as we restore the CI health of that branch. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> 16 April 2024, 21:55:55 UTC
6741e91 Johannes Schindelin 12 April 2024, 08:49:58 UTC repository: avoid leaking `fsmonitor` data The `fsmonitor` repo-setting data is allocated lazily. It needs to be released in `repo_clear()` along the rest of the allocated data in `repository`. This is needed because the next commit will merge v2.39.4, which will add a `git checkout --recurse-modules` call (which would leak memory without this here fix) to an otherwise leak-free test script. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 12 April 2024, 09:09:50 UTC
5d312ec Jeff King 05 April 2024, 20:04:51 UTC remote-curl: add Transfer-Encoding header only for older curl As of curl 7.66.0, we don't need to manually specify a "chunked" Transfer-Encoding header. Instead, modern curl deduces the need for it in a POST that has a POSTFIELDSIZE of -1 and uses READFUNCTION rather than POSTFIELDS. That version is recent enough that we can't just drop the header; we need to do so conditionally. Since it's only a single line, it seems like the simplest thing would just be to keep setting it unconditionally (after all, the #ifdefs are much longer than the actual code). But there's another wrinkle: HTTP/2. Curl may choose to use HTTP/2 under the hood if the server supports it. And in that protocol, we do not use the chunked encoding for streaming at all. Most versions of curl handle this just fine by recognizing and removing the header. But there's a regression in curl 8.7.0 and 8.7.1 where it doesn't, and large requests over HTTP/2 are broken (which t5559 notices). That regression has since been fixed upstream, but not yet released. Make the setting of this header conditional, which will let Git work even with those buggy curl versions. And as a bonus, it serves as a reminder that we can eventually clean up the code as we bump the supported curl versions. This is a backport of 92a209bf24 (remote-curl: add Transfer-Encoding header only for older curl, 2024-04-05) into the `maint-2.39` branch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 10 April 2024, 17:24:48 UTC
ea61df9 Jeff King 02 April 2024, 20:06:00 UTC INSTALL: bump libcurl version to 7.21.3 Our documentation claims we support curl versions back to 7.19.5. But we can no longer compile with that version since adding an unconditional use of CURLOPT_RESOLVE in 511cfd3bff (http: add custom hostname to IP address resolutions, 2022-05-16). That feature wasn't added to libcurl until 7.21.3. We could add #ifdefs to make this work back to 7.19.5. But given that nobody noticed the compilation failure in the intervening two years, it makes more sense to bump the version in the documentation to 7.21.3 (which is itself over 13 years old). We could perhaps go forward even more (which would let us drop some cruft from git-curl-compat.h), but this should be an obviously safe jump, and we can move forward later. Note that user-visible syntax for CURLOPT_RESOLVE has grown new features in subsequent curl versions. Our documentation mentions "+" and "-" entries, which require more recent versions than 7.21.3. We could perhaps clarify that in our docs, but it's probably not worth cluttering them with restrictions of ancient curl versions. This is a backport of c28ee09503 (INSTALL: bump libcurl version to 7.21.3, 2024-04-02) into the `maint-2.39` branch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 10 April 2024, 17:24:48 UTC
580097b Jeff King 02 April 2024, 20:05:17 UTC http: reset POSTFIELDSIZE when clearing curl handle In get_active_slot(), we return a CURL handle that may have been used before (reusing them is good because it lets curl reuse the same connection across many requests). We set a few curl options back to defaults that may have been modified by previous requests. We reset POSTFIELDS to NULL, but do not reset POSTFIELDSIZE (which defaults to "-1"). This usually doesn't matter because most POSTs will set both fields together anyway. But there is one exception: when handling a large request in remote-curl's post_rpc(), we don't set _either_, and instead set a READFUNCTION to stream data into libcurl. This can interact weirdly with a stale POSTFIELDSIZE setting, because curl will assume it should read only some set number of bytes from our READFUNCTION. However, it has worked in practice because we also manually set a "Transfer-Encoding: chunked" header, which libcurl uses as a clue to set the POSTFIELDSIZE to -1 itself. So everything works, but we're better off resetting the size manually for a few reasons: - there was a regression in curl 8.7.0 where the chunked header detection didn't kick in, causing any large HTTP requests made by Git to fail. This has since been fixed (but not yet released). In the issue, curl folks recommended setting it explicitly to -1: https://github.com/curl/curl/issues/13229#issuecomment-2029826058 and it indeed works around the regression. So even though it won't be strictly necessary after the fix there, this will help folks who end up using the affected libcurl versions. - it's consistent with what a new curl handle would look like. Since get_active_slot() may or may not return a used handle, this reduces the possibility of heisenbugs that only appear with certain request patterns. Note that the recommendation in the curl issue is to actually drop the manual Transfer-Encoding header. Modern libcurl will add the header itself when streaming from a READFUNCTION. However, that code wasn't added until 802aa5ae2 (HTTP: use chunked Transfer-Encoding for HTTP_POST if size unknown, 2019-07-22), which is in curl 7.66.0. We claim to support back to 7.19.5, so those older versions still need the manual header. This is a backport of 3242311742 (http: reset POSTFIELDSIZE when clearing curl handle, 2024-04-02) into the `maint-2.39` branch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 10 April 2024, 17:24:48 UTC
61a22dd Junio C Hamano 02 November 2023, 07:38:18 UTC Git 2.42.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 November 2023, 07:59:16 UTC
b8e45c5 Junio C Hamano 02 November 2023, 07:53:28 UTC Merge branch 'ms/doc-push-fix' into maint-2.42 Docfix. * ms/doc-push-fix: git-push doc: more visibility for -q option 02 November 2023, 07:53:28 UTC
fdb233c Junio C Hamano 02 November 2023, 07:53:28 UTC Merge branch 'jc/commit-new-underscore-index-fix' into maint-2.42 Message fix. * jc/commit-new-underscore-index-fix: commit: do not use cryptic "new_index" in end-user facing messages 02 November 2023, 07:53:28 UTC
d373ec0 Junio C Hamano 02 November 2023, 07:53:27 UTC Merge branch 'wx/merge-ort-comment-typofix' into maint-2.42 Typofix. * wx/merge-ort-comment-typofix: merge-ort.c: fix typo 'neeed' to 'needed' 02 November 2023, 07:53:27 UTC
8a26aaa Junio C Hamano 02 November 2023, 07:53:27 UTC Merge branch 'ps/git-repack-doc-fixes' into maint-2.42 Doc updates. * ps/git-repack-doc-fixes: doc/git-repack: don't mention nonexistent "--unpacked" option doc/git-repack: fix syntax for `-g` shorthand option 02 November 2023, 07:53:27 UTC
382d55a Junio C Hamano 02 November 2023, 07:53:27 UTC Merge branch 'ni/die-message-fix-for-git-add' into maint-2.42 Message updates. * ni/die-message-fix-for-git-add: builtin/add.c: clean up die() messages 02 November 2023, 07:53:27 UTC
f868596 Junio C Hamano 02 November 2023, 07:53:27 UTC Merge branch 'jc/am-doc-whitespace-action-fix' into maint-2.42 Docfix. * jc/am-doc-whitespace-action-fix: am: align placeholder for --whitespace option with apply 02 November 2023, 07:53:27 UTC
a40b8e9 Junio C Hamano 02 November 2023, 07:53:26 UTC Merge branch 'jc/update-list-references-to-lore' into maint-2.42 Doc update. * jc/update-list-references-to-lore: doc: update list archive reference to use lore.kernel.org 02 November 2023, 07:53:27 UTC
3a16179 Junio C Hamano 02 November 2023, 07:53:26 UTC Merge branch 'ps/rewritten-is-per-worktree-doc' into maint-2.42 Doc update. * ps/rewritten-is-per-worktree-doc: doc/git-worktree: mention "refs/rewritten" as per-worktree refs 02 November 2023, 07:53:26 UTC
f6a5676 Junio C Hamano 02 November 2023, 07:53:26 UTC Merge branch 'sn/cat-file-doc-update' into maint-2.42 "git cat-file" documentation updates. * sn/cat-file-doc-update: doc/cat-file: make synopsis and description less confusing 02 November 2023, 07:53:26 UTC
f92cea1 Junio C Hamano 02 November 2023, 07:53:26 UTC Merge branch 'jk/decoration-and-other-leak-fixes' into maint-2.42 Leakfix. * jk/decoration-and-other-leak-fixes: daemon: free listen_addr before returning revision: clear decoration structs during release_revisions() decorate: add clear_decoration() function 02 November 2023, 07:53:26 UTC
1e315ca Junio C Hamano 02 November 2023, 07:53:26 UTC Merge branch 'rs/parse-opt-ctx-cleanup' into maint-2.42 Code clean-up. * rs/parse-opt-ctx-cleanup: parse-options: drop unused parse_opt_ctx_t member 02 November 2023, 07:53:26 UTC
fa5799c Junio C Hamano 02 November 2023, 07:53:25 UTC Merge branch 'ob/am-msgfix' into maint-2.42 The parameters to generate an error message have been corrected. * ob/am-msgfix: am: fix error message in parse_opt_show_current_patch() 02 November 2023, 07:53:25 UTC
8a5b2e1 Junio C Hamano 02 November 2023, 07:53:25 UTC Merge branch 'hy/doc-show-is-like-log-not-diff-tree' into maint-2.42 Doc update. * hy/doc-show-is-like-log-not-diff-tree: show doc: redirect user to git log manual instead of git diff-tree 02 November 2023, 07:53:25 UTC
965d445 Junio C Hamano 02 November 2023, 07:53:25 UTC Merge branch 'ch/clean-docfix' into maint-2.42 Typofix. * ch/clean-docfix: git-clean doc: fix "without do cleaning" typo 02 November 2023, 07:53:25 UTC
905765b Junio C Hamano 02 November 2023, 07:53:24 UTC Merge branch 'eg/config-type-path-docfix' into maint-2.42 Typofix. * eg/config-type-path-docfix: git-config: fix misworded --type=path explanation 02 November 2023, 07:53:25 UTC
71c614b Junio C Hamano 02 November 2023, 07:53:24 UTC Merge branch 'ob/t3404-typofix' into maint-2.42 Code clean-up. * ob/t3404-typofix: t3404-rebase-interactive.sh: fix typos in title of a rewording test 02 November 2023, 07:53:24 UTC
cd41f66 Junio C Hamano 02 November 2023, 07:53:24 UTC Merge branch 'ob/sequencer-remove-dead-code' into maint-2.42 Code clean-up. * ob/sequencer-remove-dead-code: sequencer: remove unreachable exit condition in pick_commits() 02 November 2023, 07:53:24 UTC
f76827d Junio C Hamano 02 November 2023, 07:53:24 UTC Merge branch 'rs/name-rev-use-opt-hidden-bool' into maint-2.42 Simplify use of parse-options API a bit. * rs/name-rev-use-opt-hidden-bool: name-rev: use OPT_HIDDEN_BOOL for --peel-tag 02 November 2023, 07:53:24 UTC
2fdfd75 Junio C Hamano 02 November 2023, 07:53:23 UTC Merge branch 'rs/grep-parseopt-simplify' into maint-2.42 Simplify use of parse-options API a bit. * rs/grep-parseopt-simplify: grep: use OPT_INTEGER_F for --max-depth 02 November 2023, 07:53:24 UTC
18e0648 Junio C Hamano 02 November 2023, 07:53:23 UTC Merge branch 'ob/sequencer-reword-error-message' into maint-2.42 Update an error message (which would probably never been seen). * ob/sequencer-reword-error-message: sequencer: fix error message on failure to copy SQUASH_MSG 02 November 2023, 07:53:23 UTC
535b30e Junio C Hamano 02 November 2023, 07:53:23 UTC Merge branch 'bc/more-git-var' into maint-2.42 Fix-up for a topic that already has graduated. * bc/more-git-var: var: avoid a segmentation fault when `HOME` is unset 02 November 2023, 07:53:23 UTC
back to top