Autogenerated HTML docs for v2.45.1-145-g83f1a

RelNotes/2.39.4.txt

@@ -0,0 +1,79 @@
+Git v2.39.4 Release Notes
+=========================
+
+This addresses the security issues CVE-2024-32002, CVE-2024-32004,
+CVE-2024-32020 and CVE-2024-32021.
+
+This release also backports fixes necessary to let the CI builds pass
+successfully.
+
+Fixes since v2.39.3
+-------------------
+
+ * CVE-2024-32002:
+
+   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.
+
+ * CVE-2024-32004:
+
+   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.
+
+ * 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.
+
+ * CVE-2024-32465:
+
+   It is supposed to be safe to clone untrusted repositories, even those
+   unpacked from zip archives or tarballs originating from untrusted
+   sources, but Git can be tricked to run arbitrary code as part of the
+   clone.
+
+ * Defense-in-depth: submodule: require the submodule path to contain
+   directories only.
+
+ * Defense-in-depth: clone: when symbolic links collide with directories, keep
+   the latter.
+
+ * Defense-in-depth: clone: prevent hooks from running during a clone.
+
+ * Defense-in-depth: core.hooksPath: add some protection while cloning.
+
+ * Defense-in-depth: fsck: warn about symlink pointing inside a gitdir.
+
+ * Various fix-ups on HTTP tests.
+
+ * Test update.
+
+ * HTTP Header redaction code has been adjusted for a newer version of
+   cURL library that shows its traces differently from earlier
+   versions.
+
+ * Fix was added to work around a regression in libcURL 8.7.0 (which has
+   already been fixed in their tip of the tree).
+
+ * Replace macos-12 used at GitHub CI with macos-13.
+
+ * ci(linux-asan/linux-ubsan): let's save some time
+
+ * 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.
+
+ * Update GitHub Actions jobs to avoid warnings against using deprecated
+   version of Node.js.

RelNotes/2.40.2.txt

@@ -0,0 +1,7 @@
+Git v2.40.2 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.39.4 to address
+the security issues CVE-2024-32002, CVE-2024-32004, CVE-2024-32020,
+CVE-2024-32021 and CVE-2024-32465; see the release notes for that
+version for details.

RelNotes/2.41.1.txt

@@ -0,0 +1,7 @@
+Git v2.41.1 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.39.4 and v2.40.2
+to address the security issues CVE-2024-32002, CVE-2024-32004,
+CVE-2024-32020, CVE-2024-32021 and CVE-2024-32465; see the release
+notes for these versions for details.

RelNotes/2.42.2.txt

@@ -0,0 +1,7 @@
+Git v2.42.2 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.39.4, v2.40.2
+and v2.41.1 to address the security issues CVE-2024-32002,
+CVE-2024-32004, CVE-2024-32020, CVE-2024-32021 and CVE-2024-32465;
+see the release notes for these versions for details.

RelNotes/2.43.4.txt

@@ -0,0 +1,7 @@
+Git v2.43.4 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.39.4, v2.40.2,
+v2.41.1 and v2.42.2 to address the security issues CVE-2024-32002,
+CVE-2024-32004, CVE-2024-32020, CVE-2024-32021 and CVE-2024-32465;
+see the release notes for these versions for details.

RelNotes/2.44.1.txt

@@ -0,0 +1,8 @@
+Git v2.44.1 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.39.4, v2.40.2,
+v2.41.1, v2.42.2 and v2.43.4 to address the security issues
+CVE-2024-32002, CVE-2024-32004, CVE-2024-32020, CVE-2024-32021
+and CVE-2024-32465; see the release notes for these versions
+for details.

RelNotes/2.45.1.txt

@@ -0,0 +1,8 @@
+Git v2.45.1 Release Notes
+=========================
+
+This release merges up the fix that appears in v2.39.4,
+v2.40.2, v2.41.1, v2.42.2, v2.43.4 and v2.44.1 to address the
+security issues CVE-2024-32002, CVE-2024-32004, CVE-2024-32020,
+CVE-2024-32021 and CVE-2024-32465; see the release notes for
+these versions for details.

fsck-msgids.txt

@@ -164,6 +164,18 @@
 `nullSha1`::
 	(WARN) Tree contains entries pointing to a null sha1.
 
+`symlinkPointsToGitDir`::
+	(WARN) Symbolic link points inside a gitdir.
+
+`symlinkTargetBlob`::
+	(ERROR) A non-blob found instead of a symbolic link's target.
+
+`symlinkTargetLength`::
+	(WARN) Symbolic link target longer than maximum path length.
+
+`symlinkTargetMissing`::
+	(ERROR) Unable to read symbolic link target's blob.
+
 `treeNotSorted`::
 	(ERROR) A tree is not properly sorted.
 

git-fsck.html

@@ -1507,6 +1507,38 @@ <h2 id="_fsck_messages">FSCK MESSAGES</h2>
 </p>
 </dd>
 <dt class="hdlist1">
+<code>symlinkPointsToGitDir</code>
+</dt>
+<dd>
+<p>
+        (WARN) Symbolic link points inside a gitdir.
+</p>
+</dd>
+<dt class="hdlist1">
+<code>symlinkTargetBlob</code>
+</dt>
+<dd>
+<p>
+        (ERROR) A non-blob found instead of a symbolic link&#8217;s target.
+</p>
+</dd>
+<dt class="hdlist1">
+<code>symlinkTargetLength</code>
+</dt>
+<dd>
+<p>
+        (WARN) Symbolic link target longer than maximum path length.
+</p>
+</dd>
+<dt class="hdlist1">
+<code>symlinkTargetMissing</code>
+</dt>
+<dd>
+<p>
+        (ERROR) Unable to read symbolic link target&#8217;s blob.
+</p>
+</dd>
+<dt class="hdlist1">
 <code>treeNotSorted</code>
 </dt>
 <dd>

git-upload-pack.html

@@ -834,10 +834,47 @@ <h2 id="_environment">ENVIRONMENT</h2>
         variable to be passed. See the discussion in <a href="git.html">git(1)</a>.
 </p>
 </dd>
+<dt class="hdlist1">
+<code>GIT_NO_LAZY_FETCH</code>
+</dt>
+<dd>
+<p>
+        When cloning or fetching from a partial repository (i.e., one
+        itself cloned with <code>--filter</code>), the server-side <code>upload-pack</code>
+        may need to fetch extra objects from its upstream in order to
+        complete the request. By default, <code>upload-pack</code> will refuse to
+        perform such a lazy fetch, because <code>git fetch</code> may run arbitrary
+        commands specified in configuration and hooks of the source
+        repository (and <code>upload-pack</code> tries to be safe to run even in
+        untrusted <code>.git</code> directories).
+</p>
+<div class="paragraph"><p>This is implemented by having <code>upload-pack</code> internally set the
+<code>GIT_NO_LAZY_FETCH</code> variable to <code>1</code>. If you want to override it
+(because you are fetching from a partial clone, and you are sure
+you trust it), you can explicitly set <code>GIT_NO_LAZY_FETCH</code> to
+<code>0</code>.</p></div>
+</dd>
 </dl></div>
 </div>
 </div>
 <div class="sect1">
+<h2 id="_security">SECURITY</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>Most Git commands should not be run in an untrusted <code>.git</code> directory
+(see the section <code>SECURITY</code> in <a href="git.html">git(1)</a>). <code>upload-pack</code> tries to
+avoid any dangerous configuration options or hooks from the repository
+it&#8217;s serving, making it safe to clone an untrusted directory and run
+commands on the resulting clone.</p></div>
+<div class="paragraph"><p>For an extra level of safety, you may be able to run <code>upload-pack</code> as an
+alternate user. The details will be platform dependent, but on many
+systems you can run:</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><code>git clone --no-local --upload-pack='sudo -u nobody git-upload-pack' ...</code></pre>
+</div></div>
+</div>
+</div>
+<div class="sect1">
 <h2 id="_see_also">SEE ALSO</h2>
 <div class="sectionbody">
 <div class="paragraph"><p><a href="gitnamespaces.html">gitnamespaces(7)</a></p></div>
@@ -854,7 +891,7 @@ <h2 id="_git">GIT</h2>
 <div id="footer">
 <div id="footer-text">
 Last updated
- 2023-10-23 14:43:46 PDT
+ 2024-05-14 07:52:20 PDT
 </div>
 </div>
 </body>

git-upload-pack.txt

@@ -55,6 +55,37 @@ ENVIRONMENT
 	admins may need to configure some transports to allow this
 	variable to be passed. See the discussion in linkgit:git[1].
 
+`GIT_NO_LAZY_FETCH`::
+	When cloning or fetching from a partial repository (i.e., one
+	itself cloned with `--filter`), the server-side `upload-pack`
+	may need to fetch extra objects from its upstream in order to
+	complete the request. By default, `upload-pack` will refuse to
+	perform such a lazy fetch, because `git fetch` may run arbitrary
+	commands specified in configuration and hooks of the source
+	repository (and `upload-pack` tries to be safe to run even in
+	untrusted `.git` directories).
++
+This is implemented by having `upload-pack` internally set the
+`GIT_NO_LAZY_FETCH` variable to `1`. If you want to override it
+(because you are fetching from a partial clone, and you are sure
+you trust it), you can explicitly set `GIT_NO_LAZY_FETCH` to
+`0`.
+
+SECURITY
+--------
+
+Most Git commands should not be run in an untrusted `.git` directory
+(see the section `SECURITY` in linkgit:git[1]). `upload-pack` tries to
+avoid any dangerous configuration options or hooks from the repository
+it's serving, making it safe to clone an untrusted directory and run
+commands on the resulting clone.
+
+For an extra level of safety, you may be able to run `upload-pack` as an
+alternate user. The details will be platform dependent, but on many
+systems you can run:
+
+    git clone --no-local --upload-pack='sudo -u nobody git-upload-pack' ...
+
 SEE ALSO
 --------
 linkgit:gitnamespaces[7]

git.html

@@ -3817,6 +3817,35 @@ <h2 id="_discussion_a_id_discussion_a">Discussion<a id="Discussion"></a></h2>
 </div>
 </div>
 <div class="sect1">
+<h2 id="_security">SECURITY</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>Some configuration options and hook files may cause Git to run arbitrary
+shell commands. Because configuration and hooks are not copied using
+<code>git clone</code>, it is generally safe to clone remote repositories with
+untrusted content, inspect them with <code>git log</code>, and so on.</p></div>
+<div class="paragraph"><p>However, it is not safe to run Git commands in a <code>.git</code> directory (or
+the working tree that surrounds it) when that <code>.git</code> directory itself
+comes from an untrusted source. The commands in its config and hooks
+are executed in the usual way.</p></div>
+<div class="paragraph"><p>By default, Git will refuse to run when the repository is owned by
+someone other than the user running the command. See the entry for
+<code>safe.directory</code> in <a href="git-config.html">git-config(1)</a>. While this can help protect
+you in a multi-user environment, note that you can also acquire
+untrusted repositories that are owned by you (for example, if you
+extract a zip file or tarball from an untrusted source). In such cases,
+you&#8217;d need to "sanitize" the untrusted repository first.</p></div>
+<div class="paragraph"><p>If you have an untrusted <code>.git</code> directory, you should first clone it
+with <code>git clone --no-local</code> to obtain a clean copy. Git does restrict
+the set of options and hooks that will be run by <code>upload-pack</code>, which
+handles the server side of a clone or fetch, but beware that the
+surface area for attack against <code>upload-pack</code> is large, so this does
+carry some risk. The safest thing is to serve the repository as an
+unprivileged user (either via <a href="git-daemon.html">git-daemon(1)</a>, ssh, or using
+other tools to change user ids). See the discussion in the <code>SECURITY</code>
+section of <a href="git-upload-pack.html">git-upload-pack(1)</a>.</p></div>
+</div>
+</div>
+<div class="sect1">
 <h2 id="_further_documentation">FURTHER DOCUMENTATION</h2>
 <div class="sectionbody">
 <div class="paragraph"><p>See the references in the "description" section to get started
@@ -3879,7 +3908,7 @@ <h2 id="_git">GIT</h2>
 <div id="footer">
 <div id="footer-text">
 Last updated
- 2024-03-25 17:24:49 PDT
+ 2024-05-14 07:52:20 PDT
 </div>
 </div>
 </body>

git.txt

@@ -1067,6 +1067,37 @@ The index is also capable of storing multiple entries (called "stages")
 for a given pathname.  These stages are used to hold the various
 unmerged version of a file when a merge is in progress.
 
+SECURITY
+--------
+
+Some configuration options and hook files may cause Git to run arbitrary
+shell commands. Because configuration and hooks are not copied using
+`git clone`, it is generally safe to clone remote repositories with
+untrusted content, inspect them with `git log`, and so on.
+
+However, it is not safe to run Git commands in a `.git` directory (or
+the working tree that surrounds it) when that `.git` directory itself
+comes from an untrusted source. The commands in its config and hooks
+are executed in the usual way.
+
+By default, Git will refuse to run when the repository is owned by
+someone other than the user running the command. See the entry for
+`safe.directory` in linkgit:git-config[1]. While this can help protect
+you in a multi-user environment, note that you can also acquire
+untrusted repositories that are owned by you (for example, if you
+extract a zip file or tarball from an untrusted source). In such cases,
+you'd need to "sanitize" the untrusted repository first.
+
+If you have an untrusted `.git` directory, you should first clone it
+with `git clone --no-local` to obtain a clean copy. Git does restrict
+the set of options and hooks that will be run by `upload-pack`, which
+handles the server side of a clone or fetch, but beware that the
+surface area for attack against `upload-pack` is large, so this does
+carry some risk. The safest thing is to serve the repository as an
+unprivileged user (either via linkgit:git-daemon[1], ssh, or using
+other tools to change user ids). See the discussion in the `SECURITY`
+section of linkgit:git-upload-pack[1].
+
 FURTHER DOCUMENTATION
 ---------------------
 

howto/coordinate-embargoed-releases.html

@@ -1038,7 +1038,7 @@ <h3 id="_example_mail_to_a_href_mailto_oss_security_lists_openwall_com_oss_secur
 <div id="footer">
 <div id="footer-text">
 Last updated
- 2024-05-13 12:27:19 PDT
+ 2024-05-14 07:52:43 PDT
 </div>
 </div>
 </body>

howto/keep-canonical-history-correct.html

@@ -939,7 +939,7 @@ <h1>Keep authoritative canonical history correct with git pull</h1>
 <div id="footer">
 <div id="footer-text">
 Last updated
- 2024-05-13 12:27:19 PDT
+ 2024-05-14 07:52:43 PDT
 </div>
 </div>
 </body>

howto/maintain-git.html

@@ -1479,7 +1479,7 @@ <h3 id="_preparing_a_merge_fix">Preparing a "merge-fix"</h3>
 <div id="footer">
 <div id="footer-text">
 Last updated
- 2024-05-13 12:27:19 PDT
+ 2024-05-14 07:52:43 PDT
 </div>
 </div>
 </body>