Mirror of https://git.kernel.org/pub/scm/git/git.git/ https://git.shady.money/git/atom?h=v2.35.7 2023-02-06T08:29:44Z 2023-02-06T08:29:44Z Johannes Schindelin johannes.schindelin@gmx.de 2023-02-06T08:29:44Z urn:sha1:6a53a59bf9986f99c1a8dd0f36e2b9d6033e89f2 * maint-2.34: Git 2.34.7 http: support CURLOPT_PROTOCOLS_STR http: prefer CURLOPT_SEEKFUNCTION to CURLOPT_IOCTLFUNCTION http-push: prefer CURLOPT_UPLOAD to CURLOPT_PUT Git 2.33.7 Git 2.32.6 Git 2.31.7 Git 2.30.8 apply: fix writing behind newly created symbolic links dir-iterator: prevent top-level symlinks without FOLLOW_SYMLINKS clone: delay picking a transport until after get_repo_path() t5619: demonstrate clone_local() with ambiguous transport 2023-02-06T08:25:56Z Johannes Schindelin johannes.schindelin@gmx.de 2023-02-06T08:25:56Z urn:sha1:87248c5933891f20e47ce8153530b8ad76f53098 * maint-2.32: Git 2.32.6 Git 2.31.7 Git 2.30.8 apply: fix writing behind newly created symbolic links dir-iterator: prevent top-level symlinks without FOLLOW_SYMLINKS clone: delay picking a transport until after get_repo_path() t5619: demonstrate clone_local() with ambiguous transport 2023-02-06T08:25:08Z Johannes Schindelin johannes.schindelin@gmx.de 2023-02-06T08:25:08Z urn:sha1:aeb93d7da2bee3fac5e858b8eb89fa480d8b692e * maint-2.31: Git 2.31.7 Git 2.30.8 apply: fix writing behind newly created symbolic links dir-iterator: prevent top-level symlinks without FOLLOW_SYMLINKS clone: delay picking a transport until after get_repo_path() t5619: demonstrate clone_local() with ambiguous transport 2023-02-06T08:24:06Z Johannes Schindelin johannes.schindelin@gmx.de 2023-02-06T08:24:06Z urn:sha1:e14d6b8408a2a283e55ca64d2c77ac929ec77204 * maint-2.30: Git 2.30.8 apply: fix writing behind newly created symbolic links dir-iterator: prevent top-level symlinks without FOLLOW_SYMLINKS clone: delay picking a transport until after get_repo_path() t5619: demonstrate clone_local() with ambiguous transport 2023-02-03T22:41:31Z Patrick Steinhardt ps@pks.im 2023-02-02T10:54:34Z urn:sha1:fade728df1221598f42d391cf377e9e84a32053f 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> 2022-01-10T19:52:56Z Junio C Hamano gitster@pobox.com 2022-01-10T19:52:56Z urn:sha1:c17de5a505a2da23fcbfefdc8b0aad3f045a510f Similar message templates have been consolidated so that translators need to work on fewer number of messages. * ja/i18n-similar-messages: i18n: turn even more messages into "cannot be used together" ones i18n: ref-filter: factorize "%(foo) atom used without %(bar) atom" i18n: factorize "--foo outside a repository" i18n: refactor "unrecognized %(foo) argument" strings i18n: factorize "no directory given for --foo" i18n: factorize "--foo requires --bar" and the like i18n: tag.c factorize i18n strings i18n: standardize "cannot open" and "cannot read" i18n: turn "options are incompatible" into "cannot be used together" i18n: refactor "%s, %s and %s are mutually exclusive" i18n: refactor "foo and bar are mutually exclusive" 2022-01-10T19:52:53Z Junio C Hamano gitster@pobox.com 2022-01-10T19:52:53Z urn:sha1:bc61dbac770923a96e2007c3de4027c5d11c6d41 "git apply --3way" bypasses the attempt to do a three-way application in more cases to address the regression caused by the recent change to use direct application as a fallback. * jz/apply-3-corner-cases: git-apply: skip threeway in add / rename cases 2022-01-05T21:31:00Z Jean-Noël Avila jn.avila@free.fr 2022-01-05T20:02:22Z urn:sha1:59bb00090eb63434d46ee0ffa37482ba419aebb1 Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2022-01-05T21:29:23Z Jean-Noël Avila jn.avila@free.fr 2022-01-05T20:02:16Z urn:sha1:12909b6b8a4a51e9d2b46610be4f93c782949c80 Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-12-20T20:39:45Z Jerry Zhang jerry@skydio.com 2021-12-17T23:29:02Z urn:sha1:34d607032c0db6a6c68754e7a339c3caf08d6a79 Certain invocations of "git apply --3way" will attempt threeway and fail due to missing objects, even though git is able to fall back on apply_fragments and apply the patch successfully with a return value of 0. To fix, return early from try_threeway() in the following cases: - When the patch is a rename and no lines have changed. In this case, "git diff" doesn't record the blob info, so 3way is neither possible nor necessary. - When the patch is an addition and there is no add/add conflict, i.e. direct_to_threeway is false. In this case, threeway will fail since the preimage is not in cache, but isn't necessary anyway since there is no conflict. This fixes a few unecessary error messages when applying these kinds of patches with --3way. It also fixes a reported issue where applying a concatenation of several git produced patches will fail when those patches involve a deletion followed by creation of the same file. Add a test for this case too. (test provided by <i@zenithal.me>) Signed-off-by: Jerry Zhang <jerry@skydio.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>