packages/git
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

update version to 2.41.0

Browse Source
This commit is contained in:
fly_fzc 2023-07-14 14:13:09 +08:00
parent 94e45d7377
commit 0750433b8b
13 changed files with 9 additions and 1212 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
backport-CVE-2023-22490-attr-adjust-a-mismatched-data-type.patch
View File

@ -1,46 +0,0 @@
From 0227130244c007870c106fc613903d078730e45c Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date: Thu, 12 Jan 2023 01:05:02 +0100
Subject: [PATCH] attr: adjust a mismatched data type
On platforms where `size_t` does not have the same width as `unsigned
long`, passing a pointer to the former when a pointer to the latter is
expected can lead to problems.
Windows and 32-bit Linux are among the affected platforms.
In this instance, we want to store the size of the blob that was read in
that variable. However, `read_blob_data_from_index()` passes that
pointer to `read_object_file()` which expects an `unsigned long *`.
Which means that on affected platforms, the variable is not fully
populated and part of its value is left uninitialized. (On Big-Endian
platforms, this problem would be even worse.)
The consequence is that depending on the uninitialized memory's
contents, we may erroneously reject perfectly fine attributes.
Let's address this by passing a pointer to a variable of the expected
data type.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
attr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/attr.c b/attr.c
index f9316d14ba..c6498553db 100644
--- a/attr.c
+++ b/attr.c
@@ -745,7 +745,7 @@ static struct attr_stack *read_attr_from_index(const struct index_state *istate,
struct attr_stack *res;
char *buf, *sp;
int lineno = 0;
- size_t size;
+ unsigned long size;
if (!istate)
return NULL;
--
2.27.0

117
backport-CVE-2023-22490-clone-delay-picking-a-transport-until-after-get_repo.patch
View File

@ -1,117 +0,0 @@
From cf8f6ce02a13f4d1979a53241afbee15a293fce9 Mon Sep 17 00:00:00 2001
From: Taylor Blau <me@ttaylorr.com>
Date: Tue, 24 Jan 2023 19:43:48 -0500
Subject: [PATCH] clone: delay picking a transport until after get_repo_path()
In the previous commit, t5619 demonstrates an issue where two calls to
`get_repo_path()` could trick Git into using its local clone mechanism
in conjunction with a non-local transport.
That sequence is:
- the starting state is that the local path https:/example.com/foo is a
symlink that points to ../../../.git/modules/foo. So it's dangling.
- get_repo_path() sees that no such path exists (because it's
dangling), and thus we do not canonicalize it into an absolute path
- because we're using --separate-git-dir, we create .git/modules/foo.
Now our symlink is no longer dangling!
- we pass the url to transport_get(), which sees it as an https URL.
- we call get_repo_path() again, on the url. This second call was
introduced by f38aa83f9a (use local cloning if insteadOf makes a
local URL, 2014-07-17). The idea is that we want to pull the url
fresh from the remote.c API, because it will apply any aliases.
And of course now it sees that there is a local file, which is a
mismatch with the transport we already selected.
The issue in the above sequence is calling `transport_get()` before
deciding whether or not the repository is indeed local, and not passing
in an absolute path if it is local.
This is reminiscent of a similar bug report in [1], where it was
suggested to perform the `insteadOf` lookup earlier. Taking that
approach may not be as straightforward, since the intent is to store the
original URL in the config, but to actually fetch from the insteadOf
one, so conflating the two early on is a non-starter.
Note: we pass the path returned by `get_repo_path(remote->url[0])`,
which should be the same as `repo_name` (aside from any `insteadOf`
rewrites).
We *could* pass `absolute_pathdup()` of the same argument, which
86521acaca (Bring local clone's origin URL in line with that of a remote
clone, 2008-09-01) indicates may differ depending on the presence of
".git/" for a non-bare repo. That matters for forming relative submodule
paths, but doesn't matter for the second call, since we're just feeding
it to the transport code, which is fine either way.
[1]: https://lore.kernel.org/git/CAMoD=Bi41mB3QRn3JdZL-FGHs4w3C2jGpnJB-CqSndO7FMtfzA@mail.gmail.com/
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/clone.c | 8 ++++----
t/t5619-clone-local-ambiguous-transport.sh | 15 +++++++++++----
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index e626073b1f..c042b2e256 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -1201,10 +1201,6 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
refspec_appendf(&remote->fetch, "+%s*:%s*", src_ref_prefix,
branch_top.buf);
- transport = transport_get(remote, remote->url[0]);
- transport_set_verbosity(transport, option_verbosity, option_progress);
- transport->family = family;
-
path = get_repo_path(remote->url[0], &is_bundle);
is_local = option_local != 0 && path && !is_bundle;
if (is_local) {
@@ -1224,6 +1220,10 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
}
if (option_local > 0 && !is_local)
warning(_("--local is ignored"));
+
+ transport = transport_get(remote, path ? path : remote->url[0]);
+ transport_set_verbosity(transport, option_verbosity, option_progress);
+ transport->family = family;
transport->cloning = 1;
if (is_bundle) {
diff --git a/t/t5619-clone-local-ambiguous-transport.sh b/t/t5619-clone-local-ambiguous-transport.sh
index 7ebd31a150..cce62bf78d 100755
--- a/t/t5619-clone-local-ambiguous-transport.sh
+++ b/t/t5619-clone-local-ambiguous-transport.sh
@@ -53,11 +53,18 @@ test_expect_success 'setup' '
git -C "$REPO" update-server-info
'
-test_expect_failure 'ambiguous transport does not lead to arbitrary file-inclusion' '
+test_expect_success 'ambiguous transport does not lead to arbitrary file-inclusion' '
git clone malicious clone &&
- git -C clone submodule update --init &&
-
- test_path_is_missing clone/.git/modules/sub/objects/secret
+ test_must_fail git -C clone submodule update --init 2>err &&
+
+ test_path_is_missing clone/.git/modules/sub/objects/secret &&
+ # We would actually expect "transport .file. not allowed" here,
+ # but due to quirks of the URL detection in Git, we mis-parse
+ # the absolute path as a bogus URL and die before that step.
+ #
+ # This works for now, and if we ever fix the URL detection, it
+ # is OK to change this to detect the transport error.
+ grep "protocol .* is not supported" err
'
test_done
--
2.27.0

150
backport-CVE-2023-22490-dir-iterator-prevent-top-level-symlinks-without-FOLL.patch
View File

@ -1,150 +0,0 @@
From bffc762f87ae8d18c6001bf0044a76004245754c Mon Sep 17 00:00:00 2001
From: Taylor Blau <me@ttaylorr.com>
Date: Tue, 24 Jan 2023 19:43:51 -0500
Subject: [PATCH] dir-iterator: prevent top-level symlinks without
FOLLOW_SYMLINKS
When using the dir_iterator API, we first stat(2) the base path, and
then use that as a starting point to enumerate the directory's contents.
If the directory contains symbolic links, we will immediately die() upon
encountering them without the `FOLLOW_SYMLINKS` flag. The same is not
true when resolving the top-level directory, though.
As explained in a previous commit, this oversight in 6f054f9fb3
(builtin/clone.c: disallow `--local` clones with symlinks, 2022-07-28)
can be used as an attack vector to include arbitrary files on a victim's
filesystem from outside of the repository.
Prevent resolving top-level symlinks unless the FOLLOW_SYMLINKS flag is
given, which will cause clones of a repository with a symlink'd
"$GIT_DIR/objects" directory to fail.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
dir-iterator.c | 13 +++++++++----
dir-iterator.h | 5 +++++
t/t0066-dir-iterator.sh | 27 ++++++++++++++++++++++++++-
t/t5604-clone-reference.sh | 16 ++++++++++++++++
4 files changed, 56 insertions(+), 5 deletions(-)
diff --git a/dir-iterator.c b/dir-iterator.c
index b17e9f970a..3764dd81a1 100644
--- a/dir-iterator.c
+++ b/dir-iterator.c
@@ -203,7 +203,7 @@ struct dir_iterator *dir_iterator_begin(const char *path, unsigned int flags)
{
struct dir_iterator_int *iter = xcalloc(1, sizeof(*iter));
struct dir_iterator *dir_iterator = &iter->base;
- int saved_errno;
+ int saved_errno, err;
strbuf_init(&iter->base.path, PATH_MAX);
strbuf_addstr(&iter->base.path, path);
@@ -213,10 +213,15 @@ struct dir_iterator *dir_iterator_begin(const char *path, unsigned int flags)
iter->flags = flags;
/*
- * Note: stat already checks for NULL or empty strings and
- * inexistent paths.
+ * Note: stat/lstat already checks for NULL or empty strings and
+ * nonexistent paths.
*/
- if (stat(iter->base.path.buf, &iter->base.st) < 0) {
+ if (iter->flags & DIR_ITERATOR_FOLLOW_SYMLINKS)
+ err = stat(iter->base.path.buf, &iter->base.st);
+ else
+ err = lstat(iter->base.path.buf, &iter->base.st);
+
+ if (err < 0) {
saved_errno = errno;
goto error_out;
}
diff --git a/dir-iterator.h b/dir-iterator.h
index 08229157c6..e3b6ff2800 100644
--- a/dir-iterator.h
+++ b/dir-iterator.h
@@ -61,6 +61,11 @@
* not the symlinks themselves, which is the default behavior. Broken
* symlinks are ignored.
*
+ * Note: setting DIR_ITERATOR_FOLLOW_SYMLINKS affects resolving the
+ * starting path as well (e.g., attempting to iterate starting at a
+ * symbolic link pointing to a directory without FOLLOW_SYMLINKS will
+ * result in an error).
+ *
* Warning: circular symlinks are also followed when
* DIR_ITERATOR_FOLLOW_SYMLINKS is set. The iteration may end up with
* an ELOOP if they happen and DIR_ITERATOR_PEDANTIC is set.
diff --git a/t/t0066-dir-iterator.sh b/t/t0066-dir-iterator.sh
index 92910e4e6c..c826f60f6d 100755
--- a/t/t0066-dir-iterator.sh
+++ b/t/t0066-dir-iterator.sh
@@ -109,7 +109,9 @@ test_expect_success SYMLINKS 'setup dirs with symlinks' '
mkdir -p dir5/a/c &&
ln -s ../c dir5/a/b/d &&
ln -s ../ dir5/a/b/e &&
- ln -s ../../ dir5/a/b/f
+ ln -s ../../ dir5/a/b/f &&
+
+ ln -s dir4 dir6
'
test_expect_success SYMLINKS 'dir-iterator should not follow symlinks by default' '
@@ -145,4 +147,27 @@ test_expect_success SYMLINKS 'dir-iterator should follow symlinks w/ follow flag
test_cmp expected-follow-sorted-output actual-follow-sorted-output
'
+test_expect_success SYMLINKS 'dir-iterator does not resolve top-level symlinks' '
+ test_must_fail test-tool dir-iterator ./dir6 >out &&
+
+ grep "ENOTDIR" out
+'
+
+test_expect_success SYMLINKS 'dir-iterator resolves top-level symlinks w/ follow flag' '
+ cat >expected-follow-sorted-output <<-EOF &&
+ [d] (a) [a] ./dir6/a
+ [d] (a/f) [f] ./dir6/a/f
+ [d] (a/f/c) [c] ./dir6/a/f/c
+ [d] (b) [b] ./dir6/b
+ [d] (b/c) [c] ./dir6/b/c
+ [f] (a/d) [d] ./dir6/a/d
+ [f] (a/e) [e] ./dir6/a/e
+ EOF
+
+ test-tool dir-iterator --follow-symlinks ./dir6 >out &&
+ sort out >actual-follow-sorted-output &&
+
+ test_cmp expected-follow-sorted-output actual-follow-sorted-output
+'
+
test_done
diff --git a/t/t5604-clone-reference.sh b/t/t5604-clone-reference.sh
index 9d32f1c4a4..4ff21d7ccf 100755
--- a/t/t5604-clone-reference.sh
+++ b/t/t5604-clone-reference.sh
@@ -341,4 +341,20 @@ test_expect_success SYMLINKS 'clone repo with symlinked or unknown files at obje
test_must_be_empty T--shared.objects-symlinks.raw
'
+test_expect_success SYMLINKS 'clone repo with symlinked objects directory' '
+ test_when_finished "rm -fr sensitive malicious" &&
+
+ mkdir -p sensitive &&
+ echo "secret" >sensitive/file &&
+
+ git init malicious &&
+ rm -fr malicious/.git/objects &&
+ ln -s "$(pwd)/sensitive" ./malicious/.git/objects &&
+
+ test_must_fail git clone --local malicious clone 2>err &&
+
+ test_path_is_missing clone &&
+ grep "failed to start iterator over" err
+'
+
test_done
--
2.27.0

174
backport-CVE-2023-22490-t5619-demonstrate-clone_local-with-ambiguous-transpo.patch
View File

@ -1,174 +0,0 @@
From 58325b93c5b6212697b088371809e9948fee8052 Mon Sep 17 00:00:00 2001
From: Taylor Blau <me@ttaylorr.com>
Date: Tue, 24 Jan 2023 19:43:45 -0500
Subject: [PATCH] t5619: demonstrate clone_local() with ambiguous transport
When cloning a repository, Git must determine (a) what transport
mechanism to use, and (b) whether or not the clone is local.
Since f38aa83f9a (use local cloning if insteadOf makes a local URL,
2014-07-17), the latter check happens after the remote has been
initialized, and references the remote's URL instead of the local path.
This is done to make it possible for a `url.<base>.insteadOf` rule to
convert a remote URL into a local one, in which case the `clone_local()`
mechanism should be used.
However, with a specially crafted repository, Git can be tricked into
using a non-local transport while still setting `is_local` to "1" and
using the `clone_local()` optimization. The below test case
demonstrates such an instance, and shows that it can be used to include
arbitrary (known) paths in the working copy of a cloned repository on a
victim's machine[^1], even if local file clones are forbidden by
`protocol.file.allow`.
This happens in a few parts:
1. We first call `get_repo_path()` to see if the remote is a local
path. If it is, we replace the repo name with its absolute path.
2. We then call `transport_get()` on the repo name and decide how to
access it. If it was turned into an absolute path in the previous
step, then we should always treat it like a file.
3. We use `get_repo_path()` again, and set `is_local` as appropriate.
But it's already too late to rewrite the repo name as an absolute
path, since we've already fed it to the transport code.
The attack works by including a submodule whose URL corresponds to a
path on disk. In the below example, the repository "sub" is reachable
via the dumb HTTP protocol at (something like):
http://127.0.0.1:NNNN/dumb/sub.git
However, the path "http:/127.0.0.1:NNNN/dumb" (that is, a top-level
directory called "http:", then nested directories "127.0.0.1:NNNN", and
"dumb") exists within the repository, too.
To determine this, it first picks the appropriate transport, which is
dumb HTTP. It then uses the remote's URL in order to determine whether
the repository exists locally on disk. However, the malicious repository
also contains an embedded stub repository which is the target of a
symbolic link at the local path corresponding to the "sub" repository on
disk (i.e., there is a symbolic link at "http:/127.0.0.1/dumb/sub.git",
pointing to the stub repository via ".git/modules/sub/../../../repo").
This stub repository fools Git into thinking that a local repository
exists at that URL and thus can be cloned locally. The affected call is
in `get_repo_path()`, which in turn calls `get_repo_path_1()`, which
locates a valid repository at that target.
This then causes Git to set the `is_local` variable to "1", and in turn
instructs Git to clone the repository using its local clone optimization
via the `clone_local()` function.
The exploit comes into play because the stub repository's top-level
"$GIT_DIR/objects" directory is a symbolic link which can point to an
arbitrary path on the victim's machine. `clone_local()` resolves the
top-level "objects" directory through a `stat(2)` call, meaning that we
read through the symbolic link and copy or hardlink the directory
contents at the destination of the link.
In other words, we can get steps (1) and (3) to disagree by leveraging
the dangling symlink to pick a non-local transport in the first step,
and then set is_local to "1" in the third step when cloning with
`--separate-git-dir`, which makes the symlink non-dangling.
This can result in data-exfiltration on the victim's machine when
sensitive data is at a known path (e.g., "/home/$USER/.ssh").
The appropriate fix is two-fold:
- Resolve the transport later on (to avoid using the local
clone optimization with a non-local transport).
- Avoid reading through the top-level "objects" directory when
(correctly) using the clone_local() optimization.
This patch merely demonstrates the issue. The following two patches will
implement each part of the above fix, respectively.
[^1]: Provided that any target directory does not contain symbolic
links, in which case the changes from 6f054f9fb3 (builtin/clone.c:
disallow `--local` clones with symlinks, 2022-07-28) will abort the
clone.
Reported-by: yvvdwf <yvvdwf@gmail.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t5619-clone-local-ambiguous-transport.sh | 63 ++++++++++++++++++++++
1 file changed, 63 insertions(+)
create mode 100755 t/t5619-clone-local-ambiguous-transport.sh
diff --git a/t/t5619-clone-local-ambiguous-transport.sh b/t/t5619-clone-local-ambiguous-transport.sh
new file mode 100755
index 0000000000..7ebd31a150
--- /dev/null
+++ b/t/t5619-clone-local-ambiguous-transport.sh
@@ -0,0 +1,63 @@
+#!/bin/sh
+
+test_description='test local clone with ambiguous transport'
+
+. ./test-lib.sh
+. "$TEST_DIRECTORY/lib-httpd.sh"
+
+if ! test_have_prereq SYMLINKS
+then
+ skip_all='skipping test, symlink support unavailable'
+ test_done
+fi
+
+start_httpd
+
+REPO="$HTTPD_DOCUMENT_ROOT_PATH/sub.git"
+URI="$HTTPD_URL/dumb/sub.git"
+
+test_expect_success 'setup' '
+ mkdir -p sensitive &&
+ echo "secret" >sensitive/secret &&
+
+ git init --bare "$REPO" &&
+ test_commit_bulk -C "$REPO" --ref=main 1 &&
+
+ git -C "$REPO" update-ref HEAD main &&
+ git -C "$REPO" update-server-info &&
+
+ git init malicious &&
+ (
+ cd malicious &&
+
+ git submodule add "$URI" &&
+
+ mkdir -p repo/refs &&
+ touch repo/refs/.gitkeep &&
+ printf "ref: refs/heads/a" >repo/HEAD &&
+ ln -s "$(cd .. && pwd)/sensitive" repo/objects &&
+
+ mkdir -p "$HTTPD_URL/dumb" &&
+ ln -s "../../../.git/modules/sub/../../../repo/" "$URI" &&
+
+ git add . &&
+ git commit -m "initial commit"
+ ) &&
+
+ # Delete all of the references in our malicious submodule to
+ # avoid the client attempting to checkout any objects (which
+ # will be missing, and thus will cause the clone to fail before
+ # we can trigger the exploit).
+ git -C "$REPO" for-each-ref --format="delete %(refname)" >in &&
+ git -C "$REPO" update-ref --stdin <in &&
+ git -C "$REPO" update-server-info
+'
+
+test_expect_failure 'ambiguous transport does not lead to arbitrary file-inclusion' '
+ git clone malicious clone &&
+ git -C clone submodule update --init &&
+
+ test_path_is_missing clone/.git/modules/sub/objects/secret
+'
+
+test_done
--
2.27.0

179
backport-CVE-2023-23946-apply-fix-writing-behind-newly-created-symbolic-link.patch
View File

@ -1,179 +0,0 @@
From fade728df1221598f42d391cf377e9e84a32053f Mon Sep 17 00:00:00 2001
From: Patrick Steinhardt <ps@pks.im>
Date: Thu, 2 Feb 2023 11:54:34 +0100
Subject: [PATCH] apply: fix writing behind newly created symbolic links
When writing files git-apply(1) initially makes sure that none of the
files it is about to create are behind a symlink:
```
$ git init repo
Initialized empty Git repository in /tmp/repo/.git/
$ cd repo/
$ ln -s dir symlink
$ git apply - <<EOF
diff --git a/symlink/file b/symlink/file
new file mode 100644
index 0000000..e69de29
EOF
error: affected file 'symlink/file' is beyond a symbolic link
```
This safety mechanism is crucial to ensure that we don't write outside
of the repository's working directory. It can be fooled though when the
patch that is being applied creates the symbolic link in the first
place, which can lead to writing files in arbitrary locations.
Fix this by checking whether the path we're about to create is
beyond a symlink or not. Tightening these checks like this should be
fine as we already have these precautions in Git as explained
above. Ideally, we should update the check we do up-front before
starting to reflect the computed changes to the working tree so that
we catch this case as well, but as part of embargoed security work,
adding an equivalent check just before we try to write out a file
should serve us well as a reasonable first step.
Digging back into history shows that this vulnerability has existed
since at least Git v2.9.0. As Git v2.8.0 and older don't build on my
system anymore I cannot tell whether older versions are affected, as
well.
Reported-by: Joern Schneeweisz <jschneeweisz@gitlab.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
apply.c | 27 ++++++++++++++
t/t4115-apply-symlink.sh | 81 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 108 insertions(+)
diff --git a/apply.c b/apply.c
index 668b16e989..d80382c940 100644
--- a/apply.c
+++ b/apply.c
@@ -4400,6 +4400,33 @@ static int create_one_file(struct apply_state *state,
if (state->cached)
return 0;
+ /*
+ * We already try to detect whether files are beyond a symlink in our
+ * up-front checks. But in the case where symlinks are created by any
+ * of the intermediate hunks it can happen that our up-front checks
+ * didn't yet see the symlink, but at the point of arriving here there
+ * in fact is one. We thus repeat the check for symlinks here.
+ *
+ * Note that this does not make the up-front check obsolete as the
+ * failure mode is different:
+ *
+ * - The up-front checks cause us to abort before we have written
+ * anything into the working directory. So when we exit this way the
+ * working directory remains clean.
+ *
+ * - The checks here happen in the middle of the action where we have
+ * already started to apply the patch. The end result will be a dirty
+ * working directory.
+ *
+ * Ideally, we should update the up-front checks to catch what would
+ * happen when we apply the patch before we damage the working tree.
+ * We have all the information necessary to do so. But for now, as a
+ * part of embargoed security work, having this check would serve as a
+ * reasonable first step.
+ */
+ if (path_is_beyond_symlink(state, path))
+ return error(_("affected file '%s' is beyond a symbolic link"), path);
+
res = try_create_file(state, path, mode, buf, size);
if (res < 0)
return -1;
diff --git a/t/t4115-apply-symlink.sh b/t/t4115-apply-symlink.sh
index 872fcda6cb..1acb7b2582 100755
--- a/t/t4115-apply-symlink.sh
+++ b/t/t4115-apply-symlink.sh
@@ -44,4 +44,85 @@ test_expect_success 'apply --index symlink patch' '
'
+test_expect_success 'symlink setup' '
+ ln -s .git symlink &&
+ git add symlink &&
+ git commit -m "add symlink"
+'
+
+test_expect_success SYMLINKS 'symlink escape when creating new files' '
+ test_when_finished "git reset --hard && git clean -dfx" &&
+
+ cat >patch <<-EOF &&
+ diff --git a/symlink b/renamed-symlink
+ similarity index 100%
+ rename from symlink
+ rename to renamed-symlink
+ --
+ diff --git /dev/null b/renamed-symlink/create-me
+ new file mode 100644
+ index 0000000..039727e
+ --- /dev/null
+ +++ b/renamed-symlink/create-me
+ @@ -0,0 +1,1 @@
+ +busted
+ EOF
+
+ test_must_fail git apply patch 2>stderr &&
+ cat >expected_stderr <<-EOF &&
+ error: affected file ${SQ}renamed-symlink/create-me${SQ} is beyond a symbolic link
+ EOF
+ test_cmp expected_stderr stderr &&
+ ! test_path_exists .git/create-me
+'
+
+test_expect_success SYMLINKS 'symlink escape when modifying file' '
+ test_when_finished "git reset --hard && git clean -dfx" &&
+ touch .git/modify-me &&
+
+ cat >patch <<-EOF &&
+ diff --git a/symlink b/renamed-symlink
+ similarity index 100%
+ rename from symlink
+ rename to renamed-symlink
+ --
+ diff --git a/renamed-symlink/modify-me b/renamed-symlink/modify-me
+ index 1111111..2222222 100644
+ --- a/renamed-symlink/modify-me
+ +++ b/renamed-symlink/modify-me
+ @@ -0,0 +1,1 @@
+ +busted
+ EOF
+
+ test_must_fail git apply patch 2>stderr &&
+ cat >expected_stderr <<-EOF &&
+ error: renamed-symlink/modify-me: No such file or directory
+ EOF
+ test_cmp expected_stderr stderr &&
+ test_must_be_empty .git/modify-me
+'
+
+test_expect_success SYMLINKS 'symlink escape when deleting file' '
+ test_when_finished "git reset --hard && git clean -dfx && rm .git/delete-me" &&
+ touch .git/delete-me &&
+
+ cat >patch <<-EOF &&
+ diff --git a/symlink b/renamed-symlink
+ similarity index 100%
+ rename from symlink
+ rename to renamed-symlink
+ --
+ diff --git a/renamed-symlink/delete-me b/renamed-symlink/delete-me
+ deleted file mode 100644
+ index 1111111..0000000 100644
+ EOF
+
+ test_must_fail git apply patch 2>stderr &&
+ cat >expected_stderr <<-EOF &&
+ error: renamed-symlink/delete-me: No such file or directory
+ EOF
+ test_cmp expected_stderr stderr &&
+ test_path_is_file .git/delete-me
+'
+
test_done
--
2.27.0

90
backport-CVE-2023-25652-apply-reject-overwrite-existing-.rej-symlink-if-it-e.patch
View File

@ -1,90 +0,0 @@
From 9db05711c98efc14f414d4c87135a34c13586e0b Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Thu, 9 Mar 2023 16:02:54 +0100
Subject: [PATCH] apply --reject: overwrite existing `.rej` symlink if it
exists
The `git apply --reject` is expected to write out `.rej` files in case
one or more hunks fail to apply cleanly. Historically, the command
overwrites any existing `.rej` files. The idea being that
apply/reject/edit cycles are relatively common, and the generated `.rej`
files are not considered precious.
But the command does not overwrite existing `.rej` symbolic links, and
instead follows them. This is unsafe because the same patch could
potentially create such a symbolic link and point at arbitrary paths
outside the current worktree, and `git apply` would write the contents
of the `.rej` file into that location.
Therefore, let's make sure that any existing `.rej` file or symbolic
link is removed before writing it.
Reported-by: RyotaK <ryotak.mail@gmail.com>
Helped-by: Taylor Blau <me@ttaylorr.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Linus Torvalds <torvalds@linuxfoundation.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
apply.c | 14 ++++++++++++--
t/t4115-apply-symlink.sh | 15 +++++++++++++++
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/apply.c b/apply.c
index d80382c940..6634e9c510 100644
--- a/apply.c
+++ b/apply.c
@@ -4558,7 +4558,7 @@ static int write_out_one_reject(struct apply_state *state, struct patch *patch)
FILE *rej;
char namebuf[PATH_MAX];
struct fragment *frag;
- int cnt = 0;
+ int fd, cnt = 0;
struct strbuf sb = STRBUF_INIT;
for (cnt = 0, frag = patch->fragments; frag; frag = frag->next) {
@@ -4598,7 +4598,17 @@ static int write_out_one_reject(struct apply_state *state, struct patch *patch)
memcpy(namebuf, patch->new_name, cnt);
memcpy(namebuf + cnt, ".rej", 5);
- rej = fopen(namebuf, "w");
+ fd = open(namebuf, O_CREAT | O_EXCL | O_WRONLY, 0666);
+ if (fd < 0) {
+ if (errno != EEXIST)
+ return error_errno(_("cannot open %s"), namebuf);
+ if (unlink(namebuf))
+ return error_errno(_("cannot unlink '%s'"), namebuf);
+ fd = open(namebuf, O_CREAT | O_EXCL | O_WRONLY, 0666);
+ if (fd < 0)
+ return error_errno(_("cannot open %s"), namebuf);
+ }
+ rej = fdopen(fd, "w");
if (!rej)
return error_errno(_("cannot open %s"), namebuf);
diff --git a/t/t4115-apply-symlink.sh b/t/t4115-apply-symlink.sh
index 14e0f4d705..2d03c4e4d1 100755
--- a/t/t4115-apply-symlink.sh
+++ b/t/t4115-apply-symlink.sh
@@ -125,4 +125,19 @@ test_expect_success SYMLINKS 'symlink escape when deleting file' '
test_path_is_file .git/delete-me
'
+test_expect_success SYMLINKS '--reject removes .rej symlink if it exists' '
+ test_when_finished "git reset --hard && git clean -dfx" &&
+
+ test_commit file &&
+ echo modified >file.t &&
+ git diff -- file.t >patch &&
+ echo modified-again >file.t &&
+
+ ln -s foo file.t.rej &&
+ test_must_fail git apply patch --reject 2>err &&
+ test_i18ngrep "Rejected hunk" err &&
+ test_path_is_missing foo &&
+ test_path_is_file file.t.rej
+'
+
test_done
--
2.27.0

89
backport-CVE-2023-25815-gettext-avoid-using-gettext-if-the-locale-dir-is-not.patch
View File

@ -1,89 +0,0 @@
From c4137be0f5a6edf9a9044e6e43ecf4468c7a4046 Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Wed, 22 Feb 2023 12:40:55 +0100
Subject: [PATCH] gettext: avoid using gettext if the locale dir is not present
In cc5e1bf99247 (gettext: avoid initialization if the locale dir is not
present, 2018-04-21) Git was taught to avoid a costly gettext start-up
when there are not even any localized messages to work with.
But we still called `gettext()` and `ngettext()` functions.
Which caused a problem in Git for Windows when the libgettext that is
consumed from the MSYS2 project stopped using a runtime prefix in
https://github.com/msys2/MINGW-packages/pull/10461
Due to that change, we now use an unintialized gettext machinery that
might get auto-initialized _using an unintended locale directory_:
`C:\mingw64\share\locale`.
Let's record the fact when the gettext initialization was skipped, and
skip calling the gettext functions accordingly.
This addresses CVE-2023-25815.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
gettext.c | 4 ++++
gettext.h | 7 ++++++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/gettext.c b/gettext.c
index 1b564216d0..610d402fe7 100644
--- a/gettext.c
+++ b/gettext.c
@@ -109,6 +109,8 @@ static void init_gettext_charset(const char *domain)
setlocale(LC_CTYPE, "C");
}
+int git_gettext_enabled = 0;
+
void git_setup_gettext(void)
{
const char *podir = getenv(GIT_TEXT_DOMAIN_DIR_ENVIRONMENT);
@@ -130,6 +132,8 @@ void git_setup_gettext(void)
init_gettext_charset("git");
textdomain("git");
+ git_gettext_enabled = 1;
+
free(p);
}
diff --git a/gettext.h b/gettext.h
index bee52eb113..b96ab9d340 100644
--- a/gettext.h
+++ b/gettext.h
@@ -31,9 +31,11 @@
#define FORMAT_PRESERVING(n) __attribute__((format_arg(n)))
#ifndef NO_GETTEXT
+extern int git_gettext_enabled;
void git_setup_gettext(void);
int gettext_width(const char *s);
#else
+#define git_gettext_enabled (0)
static inline void git_setup_gettext(void)
{
}
@@ -48,6 +50,8 @@ static inline FORMAT_PRESERVING(1) const char *_(const char *msgid)
{
if (!*msgid)
return "";
+ if (!git_gettext_enabled)
+ return msgid;
return gettext(msgid);
}
@@ -56,6 +59,8 @@ static inline FORMAT_PRESERVING(1) const char *_(const char *msgid)
static inline FORMAT_PRESERVING(1) FORMAT_PRESERVING(2)
const char *Q_(const char *msgid, const char *plu, unsigned long n)
{
+ if (!git_gettext_enabled)
+ return n == 1 ? msgid : plu;
return ngettext(msgid, plu, n);
}
--
2.27.0

356
backport-CVE-2023-29007.patch
View File

@ -1,356 +0,0 @@
From 29198213c9163c1d552ee2bdbf78d2b09ccc98b8 Mon Sep 17 00:00:00 2001
From: Taylor Blau <me@ttaylorr.com>
Date: Thu, 6 Apr 2023 11:42:03 -0400
Subject: [PATCH 1/4] t1300: demonstrate failure when renaming sections with
long lines
When renaming a configuration section which has an entry whose length
exceeds the size of our buffer in config.c's implementation of
`git_config_copy_or_rename_section_in_file()`, Git will incorrectly
form a new configuration section with part of the data in the section
being removed.
In this instance, our first configuration file looks something like:
[b]
c = d <spaces> [a] e = f
[a]
g = h
Here, we have two configuration values, "b.c", and "a.g". The value "[a]
e = f" belongs to the configuration value "b.c", and does not form its
own section.
However, when renaming the section 'a' to 'xyz', Git will write back
"[xyz]\ne = f", but "[xyz]" is still attached to the value of "b.c",
which is why "e = f" on its own line becomes a new entry called "b.e".
A slightly different example embeds the section being renamed within
another section.
Demonstrate this failure in a test in t1300, which we will fix in the
following commit.
Co-authored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
---
t/t1300-config.sh | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index 1a4156c70434f3..cd8f744160e8ba 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -613,6 +613,26 @@ test_expect_success 'renaming to bogus section is rejected' '
test_must_fail git config --rename-section branch.zwei "bogus name"
'
+test_expect_failure 'renaming a section with a long line' '
+ {
+ printf "[b]\\n" &&
+ printf " c = d %1024s [a] e = f\\n" " " &&
+ printf "[a] g = h\\n"
+ } >y &&
+ git config -f y --rename-section a xyz &&
+ test_must_fail git config -f y b.e
+'
+
+test_expect_failure 'renaming an embedded section with a long line' '
+ {
+ printf "[b]\\n" &&
+ printf " c = d %1024s [a] [foo] e = f\\n" " " &&
+ printf "[a] g = h\\n"
+ } >y &&
+ git config -f y --rename-section a xyz &&
+ test_must_fail git config -f y foo.e
+'
+
cat >> .git/config << EOF
[branch "zwei"] a = 1 [branch "vier"]
EOF
From a5bb10fd5e74101e7c07da93e7c32bbe60f6173a Mon Sep 17 00:00:00 2001
From: Taylor Blau <me@ttaylorr.com>
Date: Thu, 6 Apr 2023 14:07:58 -0400
Subject: [PATCH 2/4] config: avoid fixed-sized buffer when renaming/deleting a
section
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
When renaming (or deleting) a section of configuration, Git uses the
function `git_config_copy_or_rename_section_in_file()` to rewrite the
configuration file after applying the rename or deletion to the given
section.
To do this, Git repeatedly calls `fgets()` to read the existing
configuration data into a fixed size buffer.
When the configuration value under `old_name` exceeds the size of the
buffer, we will call `fgets()` an additional time even if there is no
newline in the configuration file, since our read length is capped at
`sizeof(buf)`.
If the first character of the buffer (after zero or more characters
satisfying `isspace()`) is a '[', Git will incorrectly treat it as
beginning a new section when the original section is being removed. In
other words, a configuration value satisfying this criteria can
incorrectly be considered as a new secftion instead of a variable in the
original section.
Avoid this issue by using a variable-width buffer in the form of a
strbuf rather than a fixed-with region on the stack. A couple of small
points worth noting:
- Using a strbuf will cause us to allocate arbitrary sizes to match
the length of each line. In practice, we don't expect any
reasonable configuration files to have lines that long, and a
bandaid will be introduced in a later patch to ensure that this is
the case.
- We are using strbuf_getwholeline() here instead of strbuf_getline()
in order to match `fgets()`'s behavior of leaving the trailing LF
character on the buffer (as well as a trailing NUL).
This could be changed later, but using strbuf_getwholeline() changes
the least about this function's implementation, so it is picked as
the safest path.
- It is temping to want to replace the loop to skip over characters
matching isspace() at the beginning of the buffer with a convenience
function like `strbuf_ltrim()`. But this is the wrong approach for a
couple of reasons:
First, it involves a potentially large and expensive `memmove()`
which we would like to avoid. Second, and more importantly, we also
*do* want to preserve those spaces to avoid changing the output of
other sections.
In all, this patch is a minimal replacement of the fixed-width buffer in
`git_config_copy_or_rename_section_in_file()` to instead use a `struct
strbuf`.
Reported-by: André Baptista <andre@ethiack.com>
Reported-by: Vítor Pinho <vitor@ethiack.com>
Helped-by: Patrick Steinhardt <ps@pks.im>
Co-authored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
---
config.c | 13 +++++++------
t/t1300-config.sh | 4 ++--
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/config.c b/config.c
index 1137bd73aff07c..524347676d0da0 100644
--- a/config.c
+++ b/config.c
@@ -3091,7 +3091,7 @@ static int git_config_copy_or_rename_section_in_file(const char *config_filename
char *filename_buf = NULL;
struct lock_file lock = LOCK_INIT;
int out_fd;
- char buf[1024];
+ struct strbuf buf = STRBUF_INIT;
FILE *config_file = NULL;
struct stat st;
struct strbuf copystr = STRBUF_INIT;
@@ -3132,14 +3132,14 @@ static int git_config_copy_or_rename_section_in_file(const char *config_filename
goto out;
}
- while (fgets(buf, sizeof(buf), config_file)) {
+ while (!strbuf_getwholeline(&buf, config_file, '\n')) {
unsigned i;
int length;
int is_section = 0;
- char *output = buf;
- for (i = 0; buf[i] && isspace(buf[i]); i++)
+ char *output = buf.buf;
+ for (i = 0; buf.buf[i] && isspace(buf.buf[i]); i++)
; /* do nothing */
- if (buf[i] == '[') {
+ if (buf.buf[i] == '[') {
/* it's a section */
int offset;
is_section = 1;
@@ -3158,7 +3158,7 @@ static int git_config_copy_or_rename_section_in_file(const char *config_filename
strbuf_reset(&copystr);
}
- offset = section_name_match(&buf[i], old_name);
+ offset = section_name_match(&buf.buf[i], old_name);
if (offset > 0) {
ret++;
if (!new_name) {
@@ -3233,6 +3233,7 @@ static int git_config_copy_or_rename_section_in_file(const char *config_filename
out_no_rollback:
free(filename_buf);
config_store_data_clear(&store);
+ strbuf_release(&buf);
return ret;
}
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index cd8f744160e8ba..24c13b91dbd669 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -613,7 +613,7 @@ test_expect_success 'renaming to bogus section is rejected' '
test_must_fail git config --rename-section branch.zwei "bogus name"
'
-test_expect_failure 'renaming a section with a long line' '
+test_expect_success 'renaming a section with a long line' '
{
printf "[b]\\n" &&
printf " c = d %1024s [a] e = f\\n" " " &&
@@ -623,7 +623,7 @@ test_expect_failure 'renaming a section with a long line' '
test_must_fail git config -f y b.e
'
-test_expect_failure 'renaming an embedded section with a long line' '
+test_expect_success 'renaming an embedded section with a long line' '
{
printf "[b]\\n" &&
printf " c = d %1024s [a] [foo] e = f\\n" " " &&
From e91cfe6085c4a61372d1f800b473b73b8d225d0d Mon Sep 17 00:00:00 2001
From: Taylor Blau <me@ttaylorr.com>
Date: Thu, 6 Apr 2023 14:28:53 -0400
Subject: [PATCH 3/4] config.c: avoid integer truncation in
`copy_or_rename_section_in_file()`
There are a couple of spots within `copy_or_rename_section_in_file()`
that incorrectly use an `int` to track an offset within a string, which
may truncate or wrap around to a negative value.
Historically it was impossible to have a line longer than 1024 bytes
anyway, since we used fgets() with a fixed-size buffer of exactly that
length. But the recent change to use a strbuf permits us to read lines
of arbitrary length, so it's possible for a malicious input to cause us
to overflow past INT_MAX and do an out-of-bounds array read.
Practically speaking, however, this should never happen, since it
requires 2GB section names or values, which are unrealistic in
non-malicious circumstances.
Co-authored-by: Jeff King <peff@peff.net>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
---
config.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/config.c b/config.c
index 524347676d0da0..e4189aa2d79f62 100644
--- a/config.c
+++ b/config.c
@@ -3027,9 +3027,10 @@ void git_config_set_multivar(const char *key, const char *value,
flags);
}
-static int section_name_match (const char *buf, const char *name)
+static size_t section_name_match (const char *buf, const char *name)
{
- int i = 0, j = 0, dot = 0;
+ size_t i = 0, j = 0;
+ int dot = 0;
if (buf[i] != '[')
return 0;
for (i = 1; buf[i] && buf[i] != ']'; i++) {
@@ -3133,15 +3134,14 @@ static int git_config_copy_or_rename_section_in_file(const char *config_filename
}
while (!strbuf_getwholeline(&buf, config_file, '\n')) {
- unsigned i;
- int length;
+ size_t i, length;
int is_section = 0;
char *output = buf.buf;
for (i = 0; buf.buf[i] && isspace(buf.buf[i]); i++)
; /* do nothing */
if (buf.buf[i] == '[') {
/* it's a section */
- int offset;
+ size_t offset;
is_section = 1;
/*
From 3bb3d6bac5f2b496dfa2862dc1a84cbfa9b4449a Mon Sep 17 00:00:00 2001
From: Taylor Blau <me@ttaylorr.com>
Date: Wed, 12 Apr 2023 19:18:28 -0400
Subject: [PATCH 4/4] config.c: disallow overly-long lines in
`copy_or_rename_section_in_file()`
As a defense-in-depth measure to guard against any potentially-unknown
buffer overflows in `copy_or_rename_section_in_file()`, refuse to work
with overly-long lines in a gitconfig.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
config.c | 13 +++++++++++++
t/t1300-config.sh | 10 ++++++++++
2 files changed, 23 insertions(+)
diff --git a/config.c b/config.c
index e4189aa2d79f62..b8194dfd8a78af 100644
--- a/config.c
+++ b/config.c
@@ -3083,6 +3083,8 @@ static int section_name_is_ok(const char *name)
return 1;
}
+#define GIT_CONFIG_MAX_LINE_LEN (512 * 1024)
+
/* if new_name == NULL, the section is removed instead */
static int git_config_copy_or_rename_section_in_file(const char *config_filename,
const char *old_name,
@@ -3097,6 +3099,7 @@ static int git_config_copy_or_rename_section_in_file(const char *config_filename
struct stat st;
struct strbuf copystr = STRBUF_INIT;
struct config_store_data store;
+ uint32_t line_nr = 0;
memset(&store, 0, sizeof(store));
@@ -3137,6 +3140,16 @@ static int git_config_copy_or_rename_section_in_file(const char *config_filename
size_t i, length;
int is_section = 0;
char *output = buf.buf;
+
+ line_nr++;
+
+ if (buf.len >= GIT_CONFIG_MAX_LINE_LEN) {
+ ret = error(_("refusing to work with overly long line "
+ "in '%s' on line %"PRIuMAX),
+ config_filename, (uintmax_t)line_nr);
+ goto out;
+ }
+
for (i = 0; buf.buf[i] && isspace(buf.buf[i]); i++)
; /* do nothing */
if (buf.buf[i] == '[') {
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index 24c13b91dbd669..de564cb8e587a6 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -633,6 +633,16 @@ test_expect_success 'renaming an embedded section with a long line' '
test_must_fail git config -f y foo.e
'
+test_expect_success 'renaming a section with an overly-long line' '
+ {
+ printf "[b]\\n" &&
+ printf " c = d %525000s e" " " &&
+ printf "[a] g = h\\n"
+ } >y &&
+ test_must_fail git config -f y --rename-section a xyz 2>err &&
+ test_i18ngrep "refusing to work with overly long line in .y. on line 2" err
+'
+
cat >> .git/config << EOF
[branch "zwei"] a = 1 [branch "vier"]
EOF

BIN
git-2.39.1.tar.sign
View File

Binary file not shown.

BIN
git-2.39.1.tar.xz
View File

Binary file not shown.

BIN
git-2.41.0.tar.sign Normal file
View File

Binary file not shown.

BIN
git-2.41.0.tar.xz Normal file
View File

Binary file not shown.

20
git.spec
View File

@ -1,7 +1,7 @@
%global gitexecdir %{_libexecdir}/git-core
Name: git
Version: 2.39.1
Release: 8
Version: 2.41.0
Release: 1
Summary: A popular and widely used Version Control System
License: GPLv2+ or LGPLv2.1
URL: https://git-scm.com/
@ -17,14 +17,6 @@ Patch1: backport-CVE-2022-41953-is_Cygwin-avoid-exec-ing-anything.patch
Patch2: backport-CVE-2022-41953-Move-is_-platform-functions-to-the-beginning.patch
Patch3: backport-CVE-2022-41953-Move-the-_which-function-almost-to-the-top.patch
Patch4: backport-CVE-2022-41953-Work-around-Tcl-s-default-PATH-lookup.patch
Patch5: backport-CVE-2023-22490-attr-adjust-a-mismatched-data-type.patch
Patch6: backport-CVE-2023-22490-t5619-demonstrate-clone_local-with-ambiguous-transpo.patch
Patch7: backport-CVE-2023-22490-clone-delay-picking-a-transport-until-after-get_repo.patch
Patch8: backport-CVE-2023-22490-dir-iterator-prevent-top-level-symlinks-without-FOLL.patch
Patch9: backport-CVE-2023-23946-apply-fix-writing-behind-newly-created-symbolic-link.patch
Patch10: backport-CVE-2023-25652-apply-reject-overwrite-existing-.rej-symlink-if-it-e.patch
Patch11: backport-CVE-2023-29007.patch
Patch12: backport-CVE-2023-25815-gettext-avoid-using-gettext-if-the-locale-dir-is-not.patch
BuildRequires: gcc gettext
BuildRequires: openssl-devel libcurl-devel expat-devel systemd asciidoc xmlto glib2-devel libsecret-devel pcre2-devel desktop-file-utils
@ -257,7 +249,7 @@ make %{?_smp_mflags} test
%exclude %{_datadir}/git-core/templates/hooks/fsmonitor-watchman.sample
%exclude %{_datadir}/git-core/templates/hooks/pre-rebase.sample
%exclude %{_datadir}/git-core/templates/hooks/prepare-commit-msg.sample
%{_datadir}/locale/{bg,ca,de,el,es,fr,id,is,it,ko,pl,pt_PT,ru,sv,tr,vi,zh_CN,zh_TW}/LC_MESSAGES/git.mo
%{_datadir}/locale/{bg,ca,de,el,es,fr,id,is,it,ko,pl,pt_PT,ru,sv,uk,tr,vi,zh_CN,zh_TW}/LC_MESSAGES/git.mo
%{_datadir}/bash-completion/completions
%{_datadir}/git-core/
@ -309,6 +301,12 @@ make %{?_smp_mflags} test
%{_mandir}/man7/git*.7.*
%changelog
* Fri Jul 14 2023 fuanan <fuanan3@h-partners.com> - 2.41.0-1
- Type:enhancement
- ID:NA
- SUG:NA
- DESC:update version to 2.41.0
* Mon Jul 3 2023 huyubiao <huyubiao@huawei.com> - 2.39.1-8
- Type:bugfix
- ID:NA