diff --git a/backport-CVE-2023-22490-attr-adjust-a-mismatched-data-type.patch b/backport-CVE-2023-22490-attr-adjust-a-mismatched-data-type.patch deleted file mode 100644 index f10b9af3eb640ac676a2c83440ebbb25bbc972c8..0000000000000000000000000000000000000000 --- a/backport-CVE-2023-22490-attr-adjust-a-mismatched-data-type.patch +++ /dev/null @@ -1,46 +0,0 @@ -From 0227130244c007870c106fc613903d078730e45c Mon Sep 17 00:00:00 2001 -From: Johannes Schindelin -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 -Signed-off-by: Junio C Hamano ---- - 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 - diff --git a/backport-CVE-2023-22490-clone-delay-picking-a-transport-until-after-get_repo.patch b/backport-CVE-2023-22490-clone-delay-picking-a-transport-until-after-get_repo.patch deleted file mode 100644 index da420e71577a73f62e991a6e9cc03c366c4c51f9..0000000000000000000000000000000000000000 --- a/backport-CVE-2023-22490-clone-delay-picking-a-transport-until-after-get_repo.patch +++ /dev/null @@ -1,117 +0,0 @@ -From cf8f6ce02a13f4d1979a53241afbee15a293fce9 Mon Sep 17 00:00:00 2001 -From: Taylor Blau -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 -Signed-off-by: Taylor Blau -Signed-off-by: Junio C Hamano ---- - 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 - diff --git a/backport-CVE-2023-22490-dir-iterator-prevent-top-level-symlinks-without-FOLL.patch b/backport-CVE-2023-22490-dir-iterator-prevent-top-level-symlinks-without-FOLL.patch deleted file mode 100644 index 004cc8ca95bd95139b35c585ec9f660d5c49c1d6..0000000000000000000000000000000000000000 --- a/backport-CVE-2023-22490-dir-iterator-prevent-top-level-symlinks-without-FOLL.patch +++ /dev/null @@ -1,150 +0,0 @@ -From bffc762f87ae8d18c6001bf0044a76004245754c Mon Sep 17 00:00:00 2001 -From: Taylor Blau -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 -Signed-off-by: Junio C Hamano ---- - 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 - diff --git a/backport-CVE-2023-22490-t5619-demonstrate-clone_local-with-ambiguous-transpo.patch b/backport-CVE-2023-22490-t5619-demonstrate-clone_local-with-ambiguous-transpo.patch deleted file mode 100644 index 442e06b8b758aee366fa154ec1faa42a9ac38585..0000000000000000000000000000000000000000 --- a/backport-CVE-2023-22490-t5619-demonstrate-clone_local-with-ambiguous-transpo.patch +++ /dev/null @@ -1,174 +0,0 @@ -From 58325b93c5b6212697b088371809e9948fee8052 Mon Sep 17 00:00:00 2001 -From: Taylor Blau -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..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 -Signed-off-by: Taylor Blau -Signed-off-by: Junio C Hamano ---- - 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 -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 - < -Signed-off-by: Patrick Steinhardt -Signed-off-by: Junio C Hamano ---- - 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 - diff --git a/backport-CVE-2023-25652-apply-reject-overwrite-existing-.rej-symlink-if-it-e.patch b/backport-CVE-2023-25652-apply-reject-overwrite-existing-.rej-symlink-if-it-e.patch deleted file mode 100644 index 3544d8ba0eab11e36c9ab50db830f6b86e3c33f0..0000000000000000000000000000000000000000 --- a/backport-CVE-2023-25652-apply-reject-overwrite-existing-.rej-symlink-if-it-e.patch +++ /dev/null @@ -1,90 +0,0 @@ -From 9db05711c98efc14f414d4c87135a34c13586e0b Mon Sep 17 00:00:00 2001 -From: Johannes Schindelin -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 -Helped-by: Taylor Blau -Helped-by: Junio C Hamano -Helped-by: Linus Torvalds -Signed-off-by: Johannes Schindelin ---- - 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 - diff --git a/backport-CVE-2023-25815-gettext-avoid-using-gettext-if-the-locale-dir-is-not.patch b/backport-CVE-2023-25815-gettext-avoid-using-gettext-if-the-locale-dir-is-not.patch deleted file mode 100644 index 8166eea61fc472c98ad5283e5ffda298fd06f6a1..0000000000000000000000000000000000000000 --- a/backport-CVE-2023-25815-gettext-avoid-using-gettext-if-the-locale-dir-is-not.patch +++ /dev/null @@ -1,89 +0,0 @@ -From c4137be0f5a6edf9a9044e6e43ecf4468c7a4046 Mon Sep 17 00:00:00 2001 -From: Johannes Schindelin -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 ---- - 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 - diff --git a/backport-CVE-2023-29007.patch b/backport-CVE-2023-29007.patch deleted file mode 100644 index e221f6d13043d7f650ae605e597eb98c8f59a715..0000000000000000000000000000000000000000 --- a/backport-CVE-2023-29007.patch +++ /dev/null @@ -1,356 +0,0 @@ -From 29198213c9163c1d552ee2bdbf78d2b09ccc98b8 Mon Sep 17 00:00:00 2001 -From: Taylor Blau -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 [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 -Helped-by: Jeff King -Signed-off-by: Johannes Schindelin -Signed-off-by: Taylor Blau ---- - 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 -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 -Reported-by: Vítor Pinho -Helped-by: Patrick Steinhardt -Co-authored-by: Johannes Schindelin -Signed-off-by: Johannes Schindelin -Signed-off-by: Taylor Blau ---- - 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(©str); - } - -- 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 -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 -Signed-off-by: Jeff King -Signed-off-by: Taylor Blau ---- - 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 -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 -Signed-off-by: Johannes Schindelin ---- - 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 diff --git a/git-2.39.1.tar.sign b/git-2.39.1.tar.sign deleted file mode 100644 index e6ed440c7f0bed4f5d7566541f5c2c0b98133412..0000000000000000000000000000000000000000 Binary files a/git-2.39.1.tar.sign and /dev/null differ diff --git a/git-2.41.0.tar.sign b/git-2.41.0.tar.sign new file mode 100644 index 0000000000000000000000000000000000000000..00fb0c529e1c54c58fc2d6bad0c1ac0aa56b6b00 Binary files /dev/null and b/git-2.41.0.tar.sign differ diff --git a/git-2.39.1.tar.xz b/git-2.41.0.tar.xz similarity index 48% rename from git-2.39.1.tar.xz rename to git-2.41.0.tar.xz index ed1cbe4b329da5c76f1df895b243759d7542fbea..7e3df8c98ef531bd8cfbe5b7bfaa6735ba8bc5d0 100644 Binary files a/git-2.39.1.tar.xz and b/git-2.41.0.tar.xz differ diff --git a/git.spec b/git.spec index 8ae1a44a255db2e910a6ad532c9bf7ee95bac912..29306948f83037ddc61a57b654ceea63516b32ae 100644 --- a/git.spec +++ b/git.spec @@ -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 - 2.41.0-1 +- Type:enhancement +- ID:NA +- SUG:NA +- DESC:update version to 2.41.0 + * Mon Jul 3 2023 huyubiao - 2.39.1-8 - Type:bugfix - ID:NA