Skip to main content

Browse the archive

https://github.com/git/git
31 May 2024, 23:06:24 UTC
sort by:
Revision Author Date Message Commit Date
6c94669 Junio C Hamano 13 December 2022, 12:15:39 UTC Git 2.34.6 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 December 2022, 12:15:39 UTC
3748b5b Junio C Hamano 13 December 2022, 12:15:22 UTC Merge branch 'maint-2.33' into maint-2.34 13 December 2022, 12:15:22 UTC
7fe9bf5 Junio C Hamano 13 December 2022, 12:13:48 UTC Git 2.33.6 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 December 2022, 12:13:48 UTC
5f22dcc Junio C Hamano 13 December 2022, 12:13:11 UTC Sync with Git 2.32.5 13 December 2022, 12:13:11 UTC
d96ea53 Junio C Hamano 13 December 2022, 12:10:27 UTC Git 2.32.5 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 December 2022, 12:10:27 UTC
32e357b Junio C Hamano 13 December 2022, 12:09:56 UTC Merge branch 'ps/attr-limits-with-fsck' into maint-2.32 13 December 2022, 12:09:56 UTC
8a755ed Junio C Hamano 13 December 2022, 12:09:40 UTC Sync with Git 2.31.6 13 December 2022, 12:09:40 UTC
82689d5 Junio C Hamano 13 December 2022, 12:04:03 UTC Git 2.31.6 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 December 2022, 12:04:03 UTC
1612876 Junio C Hamano 13 December 2022, 12:02:20 UTC Sync with Git 2.30.7 13 December 2022, 12:02:20 UTC
b7b37a3 Junio C Hamano 13 December 2022, 11:56:43 UTC Git 2.30.7 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 December 2022, 11:56:43 UTC
8706a59 Junio C Hamano 11 December 2022, 00:32:48 UTC Git 2.38.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 December 2022, 00:32:48 UTC
0ddd73f Johannes Schindelin 08 November 2022, 10:13:28 UTC ci: use a newer `github-script` version The old version we currently use runs in node.js v12.x, which is being deprecated in GitHub Actions. The new version uses node.js v16.x. Incidentally, this also avoids the warning about the deprecated `::set-output::` workflow command because the newer version of the `github-script` Action uses the recommended new way to specify outputs. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Taylor Blau <me@ttaylorr.com> 10 December 2022, 07:32:16 UTC
e71f00f Junio C Hamano 10 December 2022, 07:17:47 UTC Merge branch 'jx/ci-ubuntu-fix' into maint-2.38 Adjust the GitHub CI to newer ubuntu release. * jx/ci-ubuntu-fix: ci: install python on ubuntu ci: use the same version of p4 on both Linux and macOS ci: remove the pipe after "p4 -V" to catch errors github-actions: run gcc-8 on ubuntu-20.04 image 10 December 2022, 07:17:47 UTC
ec9816c Junio C Hamano 10 December 2022, 05:02:09 UTC Merge branch 'js/ci-use-newer-up-down-artifact' into maint-2.38 CI fix. * js/ci-use-newer-up-down-artifact: ci: avoid using deprecated {up,down}load-artifacts Action 10 December 2022, 05:02:09 UTC
75efbc1 Junio C Hamano 10 December 2022, 05:02:09 UTC Merge branch 'ab/ci-use-macos-12' into maint-2.38 CI fix. * ab/ci-use-macos-12: CI: upgrade to macos-12, and pin OSX version 10 December 2022, 05:02:09 UTC
634d026 Junio C Hamano 10 December 2022, 05:02:09 UTC Merge branch 'ab/ci-retire-set-output' into maint-2.38 CI fix. * ab/ci-retire-set-output: CI: migrate away from deprecated "set-output" syntax 10 December 2022, 05:02:09 UTC
8972be0 Junio C Hamano 10 December 2022, 05:02:09 UTC Merge branch 'ab/ci-musl-bash-fix' into maint-2.38 CI fix. * ab/ci-musl-bash-fix: CI: don't explicitly pick "bash" shell outside of Windows, fix regression 10 December 2022, 05:02:09 UTC
78c5de9 Junio C Hamano 10 December 2022, 05:02:09 UTC Merge branch 'od/ci-use-checkout-v3-when-applicable' into maint-2.38 Update GitHub CI to use actions/checkout@v3; use of the older checkout@v2 gets annoying deprecation notices. * od/ci-use-checkout-v3-when-applicable: ci(main): upgrade actions/checkout to v3 10 December 2022, 05:02:09 UTC
93a7bc8 Victoria Dye 07 November 2022, 17:47:52 UTC rebase --update-refs: avoid unintended ref deletion In b3b1a21d1a5 (sequencer: rewrite update-refs as user edits todo list, 2022-07-19), the 'todo_list_filter_update_refs()' step was added to handle the removal of 'update-ref' lines from a 'rebase-todo'. Specifically, it removes potential ref updates from the "update refs state" if a ref does not have a corresponding 'update-ref' line. However, because 'write_update_refs_state()' will not update the state if the 'refs_to_oids' list was empty, removing *all* 'update-ref' lines will result in the state remaining unchanged from how it was initialized (with all refs' "after" OID being null). Then, when the ref update is applied, all refs will be updated to null and consequently deleted. To fix this, delete the 'update-refs' state file when 'refs_to_oids' is empty. Additionally, add a tests covering "all update-ref lines removed" cases. Reported-by: herr.kaste <herr.kaste@gmail.com> Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk> Helped-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 09 December 2022, 10:31:45 UTC
27ab478 Patrick Steinhardt 01 December 2022, 14:46:09 UTC fsck: implement checks for gitattributes Recently, a vulnerability was reported that can lead to an out-of-bounds write when reading an unreasonably large gitattributes file. The root cause of this error are multiple integer overflows in different parts of the code when there are either too many lines, when paths are too long, when attribute names are too long, or when there are too many attributes declared for a pattern. As all of these are related to size, it seems reasonable to restrict the size of the gitattributes file via git-fsck(1). This allows us to both stop distributing known-vulnerable objects via common hosting platforms that have fsck enabled, and users to protect themselves by enabling the `fetch.fsckObjects` config. There are basically two checks: 1. We verify that size of the gitattributes file is smaller than 100MB. 2. We verify that the maximum line length does not exceed 2048 bytes. With the preceding commits, both of these conditions would cause us to either ignore the complete gitattributes file or blob in the first case, or the specific line in the second case. Now with these consistency checks added, we also grow the ability to stop distributing such files in the first place when `receive.fsckObjects` is enabled. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2022, 08:07:04 UTC
f8587c3 Patrick Steinhardt 01 December 2022, 14:46:05 UTC fsck: move checks for gitattributes Move the checks for gitattributes so that they can be extended more readily. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2022, 08:05:00 UTC
a59a8c6 Patrick Steinhardt 01 December 2022, 14:46:01 UTC fsck: pull out function to check a set of blobs In `fsck_finish()` we check all blobs for consistency that we have found during the tree walk, but that haven't yet been checked. This is only required for gitmodules right now, but will also be required for a new check for gitattributes. Pull out a function `fsck_blobs()` that allows the caller to check a set of blobs for consistency. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2022, 08:05:00 UTC
bb3a926 Patrick Steinhardt 01 December 2022, 14:45:57 UTC fsck: refactor `fsck_blob()` to allow for more checks In general, we don't need to validate blob contents as they are opaque blobs about whose content Git doesn't need to care about. There are some exceptions though when blobs are linked into trees so that they would be interpreted by Git. We only have a single such check right now though, which is the one for gitmodules that has been added in the context of CVE-2018-11235. Now we have found another vulnerability with gitattributes that can lead to out-of-bounds writes and reads. So let's refactor `fsck_blob()` so that it is more extensible and can check different types of blobs. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2022, 08:05:00 UTC
e0bfc0b Junio C Hamano 09 December 2022, 08:03:49 UTC Merge branch 'ps/attr-limits' into maint-2.32 09 December 2022, 08:03:49 UTC
6662a83 Junio C Hamano 09 December 2022, 07:05:52 UTC Merge branch 'ps/attr-limits' into maint-2.30 09 December 2022, 07:05:52 UTC
3305300 Junio C Hamano 09 December 2022, 07:02:39 UTC Merge branch 'ps/format-padding-fix' into maint-2.30 09 December 2022, 07:02:39 UTC
304a50a Patrick Steinhardt 01 December 2022, 14:47:23 UTC pretty: restrict input lengths for padding and wrapping formats Both the padding and wrapping formatting directives allow the caller to specify an integer that ultimately leads to us adding this many chars to the result buffer. As a consequence, it is trivial to e.g. allocate 2GB of RAM via a single formatting directive and cause resource exhaustion on the machine executing this logic. Furthermore, it is debatable whether there are any sane usecases that require the user to pad data to 2GB boundaries or to indent wrapped data by 2GB. Restrict the input sizes to 16 kilobytes at a maximum to limit the amount of bytes that can be requested by the user. This is not meant as a fix because there are ways to trivially amplify the amount of data we generate via formatting directives; the real protection is achieved by the changes in previous steps to catch and avoid integer wraparound that causes us to under-allocate and access beyond the end of allocated memory reagions. But having such a limit significantly helps fuzzing the pretty format, because the fuzzer is otherwise quite fast to run out-of-memory as it discovers these formatters. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2022, 05:26:21 UTC
f930a23 Patrick Steinhardt 01 December 2022, 14:47:15 UTC utf8: refactor `strbuf_utf8_replace` to not rely on preallocated buffer In `strbuf_utf8_replace`, we preallocate the destination buffer and then use `memcpy` to copy bytes into it at computed offsets. This feels rather fragile and is hard to understand at times. Refactor the code to instead use `strbuf_add` and `strbuf_addstr` so that we can be sure that there is no possibility to perform an out-of-bounds write. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2022, 05:26:21 UTC
81c2d4c Patrick Steinhardt 01 December 2022, 14:47:10 UTC utf8: fix checking for glyph width in `strbuf_utf8_replace()` In `strbuf_utf8_replace()`, we call `utf8_width()` to compute the width of the current glyph. If the glyph is a control character though it can be that `utf8_width()` returns `-1`, but because we assign this value to a `size_t` the conversion will cause us to underflow. This bug can easily be triggered with the following command: $ git log --pretty='format:xxx%<|(1,trunc)%x10' >From all I can see though this seems to be a benign underflow that has no security-related consequences. Fix the bug by using an `int` instead. When we see a control character, we now copy it into the target buffer but don't advance the current width of the string. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2022, 05:26:21 UTC
937b71c Patrick Steinhardt 01 December 2022, 14:47:04 UTC utf8: fix overflow when returning string width The return type of both `utf8_strwidth()` and `utf8_strnwidth()` is `int`, but we operate on string lengths which are typically of type `size_t`. This means that when the string is longer than `INT_MAX`, we will overflow and thus return a negative result. This can lead to an out-of-bounds write with `--pretty=format:%<1)%B` and a commit message that is 2^31+1 bytes long: ================================================================= ==26009==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000001168 at pc 0x7f95c4e5f427 bp 0x7ffd8541c900 sp 0x7ffd8541c0a8 WRITE of size 2147483649 at 0x603000001168 thread T0 #0 0x7f95c4e5f426 in __interceptor_memcpy /usr/src/debug/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827 #1 0x5612bbb1068c in format_and_pad_commit pretty.c:1763 #2 0x5612bbb1087a in format_commit_item pretty.c:1801 #3 0x5612bbc33bab in strbuf_expand strbuf.c:429 #4 0x5612bbb110e7 in repo_format_commit_message pretty.c:1869 #5 0x5612bbb12d96 in pretty_print_commit pretty.c:2161 #6 0x5612bba0a4d5 in show_log log-tree.c:781 #7 0x5612bba0d6c7 in log_tree_commit log-tree.c:1117 #8 0x5612bb691ed5 in cmd_log_walk_no_free builtin/log.c:508 #9 0x5612bb69235b in cmd_log_walk builtin/log.c:549 #10 0x5612bb6951a2 in cmd_log builtin/log.c:883 #11 0x5612bb56c993 in run_builtin git.c:466 #12 0x5612bb56d397 in handle_builtin git.c:721 #13 0x5612bb56db07 in run_argv git.c:788 #14 0x5612bb56e8a7 in cmd_main git.c:923 #15 0x5612bb803682 in main common-main.c:57 #16 0x7f95c4c3c28f (/usr/lib/libc.so.6+0x2328f) #17 0x7f95c4c3c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349) #18 0x5612bb5680e4 in _start ../sysdeps/x86_64/start.S:115 0x603000001168 is located 0 bytes to the right of 24-byte region [0x603000001150,0x603000001168) allocated by thread T0 here: #0 0x7f95c4ebe7ea in __interceptor_realloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:85 #1 0x5612bbcdd556 in xrealloc wrapper.c:136 #2 0x5612bbc310a3 in strbuf_grow strbuf.c:99 #3 0x5612bbc32acd in strbuf_add strbuf.c:298 #4 0x5612bbc33aec in strbuf_expand strbuf.c:418 #5 0x5612bbb110e7 in repo_format_commit_message pretty.c:1869 #6 0x5612bbb12d96 in pretty_print_commit pretty.c:2161 #7 0x5612bba0a4d5 in show_log log-tree.c:781 #8 0x5612bba0d6c7 in log_tree_commit log-tree.c:1117 #9 0x5612bb691ed5 in cmd_log_walk_no_free builtin/log.c:508 #10 0x5612bb69235b in cmd_log_walk builtin/log.c:549 #11 0x5612bb6951a2 in cmd_log builtin/log.c:883 #12 0x5612bb56c993 in run_builtin git.c:466 #13 0x5612bb56d397 in handle_builtin git.c:721 #14 0x5612bb56db07 in run_argv git.c:788 #15 0x5612bb56e8a7 in cmd_main git.c:923 #16 0x5612bb803682 in main common-main.c:57 #17 0x7f95c4c3c28f (/usr/lib/libc.so.6+0x2328f) SUMMARY: AddressSanitizer: heap-buffer-overflow /usr/src/debug/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827 in __interceptor_memcpy Shadow bytes around the buggy address: 0x0c067fff81d0: fd fd fd fa fa fa fd fd fd fa fa fa fd fd fd fa 0x0c067fff81e0: fa fa fd fd fd fd fa fa fd fd fd fd fa fa fd fd 0x0c067fff81f0: fd fa fa fa fd fd fd fa fa fa fd fd fd fa fa fa 0x0c067fff8200: fd fd fd fa fa fa fd fd fd fd fa fa 00 00 00 fa 0x0c067fff8210: fa fa fd fd fd fa fa fa fd fd fd fa fa fa fd fd =>0x0c067fff8220: fd fa fa fa fd fd fd fa fa fa 00 00 00[fa]fa fa 0x0c067fff8230: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff8240: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff8250: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff8260: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff8270: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==26009==ABORTING Now the proper fix for this would be to convert both functions to return an `size_t` instead of an `int`. But given that this commit may be part of a security release, let's instead do the minimal viable fix and die in case we see an overflow. Add a test that would have previously caused us to crash. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2022, 05:26:21 UTC
17d23e8 Patrick Steinhardt 01 December 2022, 14:47:00 UTC utf8: fix returning negative string width The `utf8_strnwidth()` function calls `utf8_width()` in a loop and adds its returned width to the end result. `utf8_width()` can return `-1` though in case it reads a control character, which means that the computed string width is going to be wrong. In the worst case where there are more control characters than non-control characters, we may even return a negative string width. Fix this bug by treating control characters as having zero width. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2022, 05:26:21 UTC
522cc87 Patrick Steinhardt 01 December 2022, 14:46:53 UTC utf8: fix truncated string lengths in `utf8_strnwidth()` The `utf8_strnwidth()` function accepts an optional string length as input parameter. This parameter can either be set to `-1`, in which case we call `strlen()` on the input. Or it can be set to a positive integer that indicates a precomputed length, which callers typically compute by calling `strlen()` at some point themselves. The input parameter is an `int` though, whereas `strlen()` returns a `size_t`. This can lead to implementation-defined behaviour though when the `size_t` cannot be represented by the `int`. In the general case though this leads to wrap-around and thus to negative string sizes, which is sure enough to not lead to well-defined behaviour. Fix this by accepting a `size_t` instead of an `int` as string length. While this takes away the ability of callers to simply pass in `-1` as string length, it really is trivial enough to convert them to instead pass in `strlen()` instead. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2022, 05:26:21 UTC
48050c4 Patrick Steinhardt 01 December 2022, 14:46:49 UTC pretty: fix integer overflow in wrapping format The `%w(width,indent1,indent2)` formatting directive can be used to rewrap text to a specific width and is designed after git-shortlog(1)'s `-w` parameter. While the three parameters are all stored as `size_t` internally, `strbuf_add_wrapped_text()` accepts integers as input. As a result, the casted integers may overflow. As these now-negative integers are later on passed to `strbuf_addchars()`, we will ultimately run into implementation-defined behaviour due to casting a negative number back to `size_t` again. On my platform, this results in trying to allocate 9000 petabyte of memory. Fix this overflow by using `cast_size_t_to_int()` so that we reject inputs that cannot be represented as an integer. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2022, 05:26:21 UTC
1de69c0 Patrick Steinhardt 01 December 2022, 14:46:39 UTC pretty: fix adding linefeed when placeholder is not expanded When a formatting directive has a `+` or ` ` after the `%`, then we add either a line feed or space if the placeholder expands to a non-empty string. In specific cases though this logic doesn't work as expected, and we try to add the character even in the case where the formatting directive is empty. One such pattern is `%w(1)%+d%+w(2)`. `%+d` expands to reference names pointing to a certain commit, like in `git log --decorate`. For a tagged commit this would for example expand to `\n (tag: v1.0.0)`, which has a leading newline due to the `+` modifier and a space added by `%d`. Now the second wrapping directive will cause us to rewrap the text to `\n(tag:\nv1.0.0)`, which is one byte shorter due to the missing leading space. The code that handles the `+` magic now notices that the length has changed and will thus try to insert a leading line feed at the original posititon. But as the string was shortened, the original position is past the buffer's boundary and thus we die with an error. Now there are two issues here: 1. We check whether the buffer length has changed, not whether it has been extended. This causes us to try and add the character past the string boundary. 2. The current logic does not make any sense whatsoever. When the string got expanded due to the rewrap, putting the separator into the original position is likely to put it somewhere into the middle of the rewrapped contents. It is debatable whether `%+w()` makes any sense in the first place. Strictly speaking, the placeholder never expands to a non-empty string, and consequentially we shouldn't ever accept this combination. We thus fix the bug by simply refusing `%+w()`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2022, 05:26:21 UTC
f6e0b9f Patrick Steinhardt 01 December 2022, 14:46:34 UTC pretty: fix out-of-bounds read when parsing invalid padding format An out-of-bounds read can be triggered when parsing an incomplete padding format string passed via `--pretty=format` or in Git archives when files are marked with the `export-subst` gitattribute. This bug exists since we have introduced support for truncating output via the `trunc` keyword a7f01c6b4d (pretty: support truncating in %>, %< and %><, 2013-04-19). Before this commit, we used to find the end of the formatting string by using strchr(3P). This function returns a `NULL` pointer in case the character in question wasn't found. The subsequent check whether any character was found thus simply checked the returned pointer. After the commit we switched to strcspn(3P) though, which only returns the offset to the first found character or to the trailing NUL byte. As the end pointer is now computed by adding the offset to the start pointer it won't be `NULL` anymore, and as a consequence the check doesn't do anything anymore. The out-of-bounds data that is being read can in fact end up in the formatted string. As a consequence, it is possible to leak memory contents either by calling git-log(1) or via git-archive(1) when any of the archived files is marked with the `export-subst` gitattribute. ==10888==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000398 at pc 0x7f0356047cb2 bp 0x7fff3ffb95d0 sp 0x7fff3ffb8d78 READ of size 1 at 0x602000000398 thread T0 #0 0x7f0356047cb1 in __interceptor_strchrnul /usr/src/debug/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:725 #1 0x563b7cec9a43 in strbuf_expand strbuf.c:417 #2 0x563b7cda7060 in repo_format_commit_message pretty.c:1869 #3 0x563b7cda8d0f in pretty_print_commit pretty.c:2161 #4 0x563b7cca04c8 in show_log log-tree.c:781 #5 0x563b7cca36ba in log_tree_commit log-tree.c:1117 #6 0x563b7c927ed5 in cmd_log_walk_no_free builtin/log.c:508 #7 0x563b7c92835b in cmd_log_walk builtin/log.c:549 #8 0x563b7c92b1a2 in cmd_log builtin/log.c:883 #9 0x563b7c802993 in run_builtin git.c:466 #10 0x563b7c803397 in handle_builtin git.c:721 #11 0x563b7c803b07 in run_argv git.c:788 #12 0x563b7c8048a7 in cmd_main git.c:923 #13 0x563b7ca99682 in main common-main.c:57 #14 0x7f0355e3c28f (/usr/lib/libc.so.6+0x2328f) #15 0x7f0355e3c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349) #16 0x563b7c7fe0e4 in _start ../sysdeps/x86_64/start.S:115 0x602000000398 is located 0 bytes to the right of 8-byte region [0x602000000390,0x602000000398) allocated by thread T0 here: #0 0x7f0356072faa in __interceptor_strdup /usr/src/debug/gcc/libsanitizer/asan/asan_interceptors.cpp:439 #1 0x563b7cf7317c in xstrdup wrapper.c:39 #2 0x563b7cd9a06a in save_user_format pretty.c:40 #3 0x563b7cd9b3e5 in get_commit_format pretty.c:173 #4 0x563b7ce54ea0 in handle_revision_opt revision.c:2456 #5 0x563b7ce597c9 in setup_revisions revision.c:2850 #6 0x563b7c9269e0 in cmd_log_init_finish builtin/log.c:269 #7 0x563b7c927362 in cmd_log_init builtin/log.c:348 #8 0x563b7c92b193 in cmd_log builtin/log.c:882 #9 0x563b7c802993 in run_builtin git.c:466 #10 0x563b7c803397 in handle_builtin git.c:721 #11 0x563b7c803b07 in run_argv git.c:788 #12 0x563b7c8048a7 in cmd_main git.c:923 #13 0x563b7ca99682 in main common-main.c:57 #14 0x7f0355e3c28f (/usr/lib/libc.so.6+0x2328f) #15 0x7f0355e3c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349) #16 0x563b7c7fe0e4 in _start ../sysdeps/x86_64/start.S:115 SUMMARY: AddressSanitizer: heap-buffer-overflow /usr/src/debug/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:725 in __interceptor_strchrnul Shadow bytes around the buggy address: 0x0c047fff8020: fa fa fd fd fa fa 00 06 fa fa 05 fa fa fa fd fd 0x0c047fff8030: fa fa 00 02 fa fa 06 fa fa fa 05 fa fa fa fd fd 0x0c047fff8040: fa fa 00 07 fa fa 03 fa fa fa fd fd fa fa 00 00 0x0c047fff8050: fa fa 00 01 fa fa fd fd fa fa 00 00 fa fa 00 01 0x0c047fff8060: fa fa 00 06 fa fa 00 06 fa fa 05 fa fa fa 05 fa =>0x0c047fff8070: fa fa 00[fa]fa fa fd fa fa fa fd fd fa fa fd fd 0x0c047fff8080: fa fa fd fd fa fa 00 00 fa fa 00 fa fa fa fd fa 0x0c047fff8090: fa fa fd fd fa fa 00 00 fa fa fa fa fa fa fa fa 0x0c047fff80a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff80b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff80c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==10888==ABORTING Fix this bug by checking whether `end` points at the trailing NUL byte. Add a test which catches this out-of-bounds read and which demonstrates that we used to write out-of-bounds data into the formatted message. Reported-by: Markus Vervier <markus.vervier@x41-dsec.de> Original-patch-by: Markus Vervier <markus.vervier@x41-dsec.de> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2022, 05:26:21 UTC
b49f309 Patrick Steinhardt 01 December 2022, 14:46:30 UTC pretty: fix out-of-bounds read when left-flushing with stealing With the `%>>(<N>)` pretty formatter, you can ask git-log(1) et al to steal spaces. To do so we need to look ahead of the next token to see whether there are spaces there. This loop takes into account ANSI sequences that end with an `m`, and if it finds any it will skip them until it finds the first space. While doing so it does not take into account the buffer's limits though and easily does an out-of-bounds read. Add a test that hits this behaviour. While we don't have an easy way to verify this, the test causes the following failure when run with `SANITIZE=address`: ==37941==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000000baf at pc 0x55ba6f88e0d0 bp 0x7ffc84c50d20 sp 0x7ffc84c50d10 READ of size 1 at 0x603000000baf thread T0 #0 0x55ba6f88e0cf in format_and_pad_commit pretty.c:1712 #1 0x55ba6f88e7b4 in format_commit_item pretty.c:1801 #2 0x55ba6f9b1ae4 in strbuf_expand strbuf.c:429 #3 0x55ba6f88f020 in repo_format_commit_message pretty.c:1869 #4 0x55ba6f890ccf in pretty_print_commit pretty.c:2161 #5 0x55ba6f7884c8 in show_log log-tree.c:781 #6 0x55ba6f78b6ba in log_tree_commit log-tree.c:1117 #7 0x55ba6f40fed5 in cmd_log_walk_no_free builtin/log.c:508 #8 0x55ba6f41035b in cmd_log_walk builtin/log.c:549 #9 0x55ba6f4131a2 in cmd_log builtin/log.c:883 #10 0x55ba6f2ea993 in run_builtin git.c:466 #11 0x55ba6f2eb397 in handle_builtin git.c:721 #12 0x55ba6f2ebb07 in run_argv git.c:788 #13 0x55ba6f2ec8a7 in cmd_main git.c:923 #14 0x55ba6f581682 in main common-main.c:57 #15 0x7f2d08c3c28f (/usr/lib/libc.so.6+0x2328f) #16 0x7f2d08c3c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349) #17 0x55ba6f2e60e4 in _start ../sysdeps/x86_64/start.S:115 0x603000000baf is located 1 bytes to the left of 24-byte region [0x603000000bb0,0x603000000bc8) allocated by thread T0 here: #0 0x7f2d08ebe7ea in __interceptor_realloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:85 #1 0x55ba6fa5b494 in xrealloc wrapper.c:136 #2 0x55ba6f9aefdc in strbuf_grow strbuf.c:99 #3 0x55ba6f9b0a06 in strbuf_add strbuf.c:298 #4 0x55ba6f9b1a25 in strbuf_expand strbuf.c:418 #5 0x55ba6f88f020 in repo_format_commit_message pretty.c:1869 #6 0x55ba6f890ccf in pretty_print_commit pretty.c:2161 #7 0x55ba6f7884c8 in show_log log-tree.c:781 #8 0x55ba6f78b6ba in log_tree_commit log-tree.c:1117 #9 0x55ba6f40fed5 in cmd_log_walk_no_free builtin/log.c:508 #10 0x55ba6f41035b in cmd_log_walk builtin/log.c:549 #11 0x55ba6f4131a2 in cmd_log builtin/log.c:883 #12 0x55ba6f2ea993 in run_builtin git.c:466 #13 0x55ba6f2eb397 in handle_builtin git.c:721 #14 0x55ba6f2ebb07 in run_argv git.c:788 #15 0x55ba6f2ec8a7 in cmd_main git.c:923 #16 0x55ba6f581682 in main common-main.c:57 #17 0x7f2d08c3c28f (/usr/lib/libc.so.6+0x2328f) #18 0x7f2d08c3c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349) #19 0x55ba6f2e60e4 in _start ../sysdeps/x86_64/start.S:115 SUMMARY: AddressSanitizer: heap-buffer-overflow pretty.c:1712 in format_and_pad_commit Shadow bytes around the buggy address: 0x0c067fff8120: fa fa fd fd fd fa fa fa fd fd fd fa fa fa fd fd 0x0c067fff8130: fd fd fa fa fd fd fd fd fa fa fd fd fd fa fa fa 0x0c067fff8140: fd fd fd fa fa fa fd fd fd fa fa fa fd fd fd fa 0x0c067fff8150: fa fa fd fd fd fd fa fa 00 00 00 fa fa fa fd fd 0x0c067fff8160: fd fa fa fa fd fd fd fa fa fa fd fd fd fa fa fa =>0x0c067fff8170: fd fd fd fa fa[fa]00 00 00 fa fa fa 00 00 00 fa 0x0c067fff8180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff8190: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff81a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff81b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff81c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Luckily enough, this would only cause us to copy the out-of-bounds data into the formatted commit in case we really had an ANSI sequence preceding our buffer. So this bug likely has no security consequences. Fix it regardless by not traversing past the buffer's start. Reported-by: Patrick Steinhardt <ps@pks.im> Reported-by: Eric Sesterhenn <eric.sesterhenn@x41-dsec.de> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2022, 05:26:21 UTC
81dc898 Patrick Steinhardt 01 December 2022, 14:46:25 UTC pretty: fix out-of-bounds write caused by integer overflow When using a padding specifier in the pretty format passed to git-log(1) we need to calculate the string length in several places. These string lengths are stored in `int`s though, which means that these can easily overflow when the input lengths exceeds 2GB. This can ultimately lead to an out-of-bounds write when these are used in a call to memcpy(3P): ==8340==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f1ec62f97fe at pc 0x7f2127e5f427 bp 0x7ffd3bd63de0 sp 0x7ffd3bd63588 WRITE of size 1 at 0x7f1ec62f97fe thread T0 #0 0x7f2127e5f426 in __interceptor_memcpy /usr/src/debug/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827 #1 0x5628e96aa605 in format_and_pad_commit pretty.c:1762 #2 0x5628e96aa7f4 in format_commit_item pretty.c:1801 #3 0x5628e97cdb24 in strbuf_expand strbuf.c:429 #4 0x5628e96ab060 in repo_format_commit_message pretty.c:1869 #5 0x5628e96acd0f in pretty_print_commit pretty.c:2161 #6 0x5628e95a44c8 in show_log log-tree.c:781 #7 0x5628e95a76ba in log_tree_commit log-tree.c:1117 #8 0x5628e922bed5 in cmd_log_walk_no_free builtin/log.c:508 #9 0x5628e922c35b in cmd_log_walk builtin/log.c:549 #10 0x5628e922f1a2 in cmd_log builtin/log.c:883 #11 0x5628e9106993 in run_builtin git.c:466 #12 0x5628e9107397 in handle_builtin git.c:721 #13 0x5628e9107b07 in run_argv git.c:788 #14 0x5628e91088a7 in cmd_main git.c:923 #15 0x5628e939d682 in main common-main.c:57 #16 0x7f2127c3c28f (/usr/lib/libc.so.6+0x2328f) #17 0x7f2127c3c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349) #18 0x5628e91020e4 in _start ../sysdeps/x86_64/start.S:115 0x7f1ec62f97fe is located 2 bytes to the left of 4831838265-byte region [0x7f1ec62f9800,0x7f1fe62f9839) allocated by thread T0 here: #0 0x7f2127ebe7ea in __interceptor_realloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:85 #1 0x5628e98774d4 in xrealloc wrapper.c:136 #2 0x5628e97cb01c in strbuf_grow strbuf.c:99 #3 0x5628e97ccd42 in strbuf_addchars strbuf.c:327 #4 0x5628e96aa55c in format_and_pad_commit pretty.c:1761 #5 0x5628e96aa7f4 in format_commit_item pretty.c:1801 #6 0x5628e97cdb24 in strbuf_expand strbuf.c:429 #7 0x5628e96ab060 in repo_format_commit_message pretty.c:1869 #8 0x5628e96acd0f in pretty_print_commit pretty.c:2161 #9 0x5628e95a44c8 in show_log log-tree.c:781 #10 0x5628e95a76ba in log_tree_commit log-tree.c:1117 #11 0x5628e922bed5 in cmd_log_walk_no_free builtin/log.c:508 #12 0x5628e922c35b in cmd_log_walk builtin/log.c:549 #13 0x5628e922f1a2 in cmd_log builtin/log.c:883 #14 0x5628e9106993 in run_builtin git.c:466 #15 0x5628e9107397 in handle_builtin git.c:721 #16 0x5628e9107b07 in run_argv git.c:788 #17 0x5628e91088a7 in cmd_main git.c:923 #18 0x5628e939d682 in main common-main.c:57 #19 0x7f2127c3c28f (/usr/lib/libc.so.6+0x2328f) #20 0x7f2127c3c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349) #21 0x5628e91020e4 in _start ../sysdeps/x86_64/start.S:115 SUMMARY: AddressSanitizer: heap-buffer-overflow /usr/src/debug/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827 in __interceptor_memcpy Shadow bytes around the buggy address: 0x0fe458c572a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0fe458c572b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0fe458c572c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0fe458c572d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0fe458c572e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0fe458c572f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa[fa] 0x0fe458c57300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe458c57310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe458c57320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe458c57330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe458c57340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==8340==ABORTING The pretty format can also be used in `git archive` operations via the `export-subst` attribute. So this is what in our opinion makes this a critical issue in the context of Git forges which allow to download an archive of user supplied Git repositories. Fix this vulnerability by using `size_t` instead of `int` to track the string lengths. Add tests which detect this vulnerability when Git is compiled with the address sanitizer. Reported-by: Joern Schneeweisz <jschneeweisz@gitlab.com> Original-patch-by: Joern Schneeweisz <jschneeweisz@gitlab.com> Modified-by: Taylor Blau <me@ttalorr.com> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2022, 05:26:21 UTC
a244dc5 Carlo Marcelo Arenas Belón 02 November 2021, 15:46:06 UTC test-lib: add prerequisite for 64-bit platforms Allow tests that assume a 64-bit `size_t` to be skipped in 32-bit platforms and regardless of the size of `long`. This imitates the `LONG_IS_64BIT` prerequisite. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 December 2022, 05:26:04 UTC
f115c96 Ævar Arnfjörð Bjarmason 07 December 2022, 01:49:18 UTC CI: migrate away from deprecated "set-output" syntax As noted in [1] and the warnings the CI itself is spewing echoing outputs to stdout is deprecated, and they should be written to "$GITHUB_OUTPUT" instead. 1. https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 December 2022, 23:47:22 UTC
1f39844 Johannes Schindelin 07 December 2022, 14:34:39 UTC ci: avoid using deprecated {up,down}load-artifacts Action The deprecated versions of these Actions still use node.js 12 whereas workflows will need to use node.js 16 to avoid problems going forward. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 December 2022, 23:15:23 UTC
d8b21a0 Ævar Arnfjörð Bjarmason 07 December 2022, 12:03:15 UTC CI: don't explicitly pick "bash" shell outside of Windows, fix regression When the "js/ci-github-workflow-markup" topic was originally merged in [1] it included a change to get rid of the "ci/print-test-failures.sh" step[2]. This was then brought back in [3] as part of a fix-up patches on top[4]. The problem was that [3] was not a revert of the relevant parts of [2], but rather copy/pasted the "ci/print-test-failures.sh" step that was present for the Windows job to all "ci/print-test-failures.sh" steps. The Windows steps specified "shell: bash", but the non-Windows ones did not. This broke the "ci/print/test-failures.sh" step for the "linux-musl" job, where we don't have a "bash" shell, just a "/bin/sh" (a "dash"). This breakage was reported at the time[5], but hadn't been fixed. It would be sufficient to change this only for "linux-musl", but let's change this for both "regular" and "dockerized" to omit the "shell" line entirely, as we did before [2]. Let's also change undo the "name" change that [3] made while copy/pasting the "print test failures" step for the Windows job. These steps are now the same as they were before [2], except that the "if" includes the "env.FAILED_TEST_ARTIFACTS" test. 1. fc5a070f591 (Merge branch 'js/ci-github-workflow-markup', 2022-06-07) 2. 08dccc8fc1f (ci: make it easier to find failed tests' logs in the GitHub workflow, 2022-05-21) 3. 5aeb145780f (ci(github): bring back the 'print test failures' step, 2022-06-08) 4. d0d96b8280f (Merge branch 'js/ci-github-workflow-markup', 2022-06-17) 5. https://lore.kernel.org/git/220725.86sfmpneqp.gmgdl@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 December 2022, 23:06:00 UTC
d111922 Ævar Arnfjörð Bjarmason 06 December 2022, 19:57:56 UTC CI: upgrade to macos-12, and pin OSX version Per [1] and the warnings our CI is emitting GitHub is phasing in "macos-12" as their "macos-latest". As with [2], let's pin our image to a specific version so that we're not having it swept from under us, and our upgrade cycle can be more predictable than whenever GitHub changes their images. 1. https://github.com/actions/runner-images/issues/6384 2. 0178420b9ca (github-actions: run gcc-8 on ubuntu-20.04 image, 2022-11-25) Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 December 2022, 04:36:22 UTC
6cf4d90 Oscar Dominguez 05 December 2022, 10:01:14 UTC ci(main): upgrade actions/checkout to v3 To be up to date with actions/checkout opens the door to use the latest features if necessary and get the latest security patches. This also avoids a couple of deprecation warnings in the CI runs. Note: The `actions/checkout` Action has been known to be broken in i686 containers as of v2, therefore we keep forcing it to v1 there. See actions/runner#2115 for more details. Signed-off-by: Oscar Dominguez <dominguez.celada@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 December 2022, 23:22:15 UTC
3c50032 Patrick Steinhardt 01 December 2022, 14:45:53 UTC attr: ignore overly large gitattributes files Similar as with the preceding commit, start ignoring gitattributes files that are overly large to protect us against out-of-bounds reads and writes caused by integer overflows. Unfortunately, we cannot just define "overly large" in terms of any preexisting limits in the codebase. Instead, we choose a very conservative limit of 100MB. This is plenty of room for specifying gitattributes, and incidentally it is also the limit for blob sizes for GitHub. While we don't want GitHub to dictate limits here, it is still sensible to use this fact for an informed decision given that it is hosting a huge set of repositories. Furthermore, over at GitLab we scanned a subset of repositories for their root-level attribute files. We found that 80% of them have a gitattributes file smaller than 100kB, 99.99% have one smaller than 1MB, and only a single repository had one that was almost 3MB in size. So enforcing a limit of 100MB seems to give us ample of headroom. With this limit in place we can be reasonably sure that there is no easy way to exploit the gitattributes file via integer overflows anymore. Furthermore, it protects us against resource exhaustion caused by allocating the in-memory data structures required to represent the parsed attributes. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 December 2022, 06:50:03 UTC
dfa6b32 Patrick Steinhardt 01 December 2022, 14:45:48 UTC attr: ignore attribute lines exceeding 2048 bytes There are two different code paths to read gitattributes: once via a file, and once via the index. These two paths used to behave differently because when reading attributes from a file, we used fgets(3P) with a buffer size of 2kB. Consequentially, we silently truncate line lengths when lines are longer than that and will then parse the remainder of the line as a new pattern. It goes without saying that this is entirely unexpected, but it's even worse that the behaviour depends on how the gitattributes are parsed. While this is simply wrong, the silent truncation saves us with the recently discovered vulnerabilities that can cause out-of-bound writes or reads with unreasonably long lines due to integer overflows. As the common path is to read gitattributes via the worktree file instead of via the index, we can assume that any gitattributes file that had lines longer than that is already broken anyway. So instead of lifting the limit here, we can double down on it to fix the vulnerabilities. Introduce an explicit line length limit of 2kB that is shared across all paths that read attributes and ignore any line that hits this limit while printing a warning. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 December 2022, 06:33:07 UTC
d74b1fd Patrick Steinhardt 01 December 2022, 14:45:44 UTC attr: fix silently splitting up lines longer than 2048 bytes When reading attributes from a file we use fgets(3P) with a buffer size of 2048 bytes. This means that as soon as a line exceeds the buffer size we split it up into multiple parts and parse each of them as a separate pattern line. This is of course not what the user intended, and even worse the behaviour is inconsistent with how we read attributes from the index. Fix this bug by converting the code to use `strbuf_getline()` instead. This will indeed read in the whole line, which may theoretically lead to an out-of-memory situation when the gitattributes file is huge. We're about to reject any gitattributes files larger than 100MB in the next commit though, which makes this less of a concern. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 December 2022, 06:29:30 UTC
a60a66e Patrick Steinhardt 01 December 2022, 14:45:40 UTC attr: harden allocation against integer overflows When parsing an attributes line, we need to allocate an array that holds all attributes specified for the given file pattern. The calculation to determine the number of bytes that need to be allocated was prone to an overflow though when there was an unreasonable amount of attributes. Harden the allocation by instead using the `st_` helper functions that cause us to die when we hit an integer overflow. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 December 2022, 06:14:16 UTC
e1e12e9 Patrick Steinhardt 01 December 2022, 14:45:36 UTC attr: fix integer overflow with more than INT_MAX macros Attributes have a field that tracks the position in the `all_attrs` array they're stored inside. This field gets set via `hashmap_get_size` when adding the attribute to the global map of attributes. But while the field is of type `int`, the value returned by `hashmap_get_size` is an `unsigned int`. It can thus happen that the value overflows, where we would now dereference teh `all_attrs` array at an out-of-bounds value. We do have a sanity check for this overflow via an assert that verifies the index matches the new hashmap's size. But asserts are not a proper mechanism to detect against any such overflows as they may not in fact be compiled into production code. Fix this by using an `unsigned int` to track the index and convert the assert to a call `die()`. Reported-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 December 2022, 06:14:16 UTC
447ac90 Patrick Steinhardt 01 December 2022, 14:45:31 UTC attr: fix out-of-bounds read with unreasonable amount of patterns The `struct attr_stack` tracks the stack of all patterns together with their attributes. When parsing a gitattributes file that has more than 2^31 such patterns though we may trigger multiple out-of-bounds reads on 64 bit platforms. This is because while the `num_matches` variable is an unsigned integer, we always use a signed integer to iterate over them. I have not been able to reproduce this issue due to memory constraints on my systems. But despite the out-of-bounds reads, the worst thing that can seemingly happen is to call free(3P) with a garbage pointer when calling `attr_stack_free()`. Fix this bug by using unsigned integers to iterate over the array. While this makes the iteration somewhat awkward when iterating in reverse, it is at least better than knowingly running into an out-of-bounds read. While at it, convert the call to `ALLOC_GROW` to use `ALLOC_GROW_BY` instead. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 December 2022, 06:14:16 UTC
34ace8b Patrick Steinhardt 01 December 2022, 14:45:27 UTC attr: fix out-of-bounds write when parsing huge number of attributes It is possible to trigger an integer overflow when parsing attribute names when there are more than 2^31 of them for a single pattern. This can either lead to us dying due to trying to request too many bytes: blob=$(perl -e 'print "f" . " a=" x 2147483649' | git hash-object -w --stdin) git update-index --add --cacheinfo 100644,$blob,.gitattributes git attr-check --all file ================================================================= ==1022==ERROR: AddressSanitizer: requested allocation size 0xfffffff800000032 (0xfffffff800001038 after adjustments for alignment, red zones etc.) exceeds maximum supported size of 0x10000000000 (thread T0) #0 0x7fd3efabf411 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77 #1 0x5563a0a1e3d3 in xcalloc wrapper.c:150 #2 0x5563a058d005 in parse_attr_line attr.c:384 #3 0x5563a058e661 in handle_attr_line attr.c:660 #4 0x5563a058eddb in read_attr_from_index attr.c:769 #5 0x5563a058ef12 in read_attr attr.c:797 #6 0x5563a058f24c in bootstrap_attr_stack attr.c:867 #7 0x5563a058f4a3 in prepare_attr_stack attr.c:902 #8 0x5563a05905da in collect_some_attrs attr.c:1097 #9 0x5563a059093d in git_all_attrs attr.c:1128 #10 0x5563a02f636e in check_attr builtin/check-attr.c:67 #11 0x5563a02f6c12 in cmd_check_attr builtin/check-attr.c:183 #12 0x5563a02aa993 in run_builtin git.c:466 #13 0x5563a02ab397 in handle_builtin git.c:721 #14 0x5563a02abb2b in run_argv git.c:788 #15 0x5563a02ac991 in cmd_main git.c:926 #16 0x5563a05432bd in main common-main.c:57 #17 0x7fd3ef82228f (/usr/lib/libc.so.6+0x2328f) ==1022==HINT: if you don't care about these errors you may set allocator_may_return_null=1 SUMMARY: AddressSanitizer: allocation-size-too-big /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77 in __interceptor_calloc ==1022==ABORTING Or, much worse, it can lead to an out-of-bounds write because we underallocate and then memcpy(3P) into an array: perl -e ' print "A " . "\rh="x2000000000; print "\rh="x2000000000; print "\rh="x294967294 . "\n" ' >.gitattributes git add .gitattributes git commit -am "evil attributes" $ git clone --quiet /path/to/repo ================================================================= ==15062==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000002550 at pc 0x5555559884d5 bp 0x7fffffffbc60 sp 0x7fffffffbc58 WRITE of size 8 at 0x602000002550 thread T0 #0 0x5555559884d4 in parse_attr_line attr.c:393 #1 0x5555559884d4 in handle_attr_line attr.c:660 #2 0x555555988902 in read_attr_from_index attr.c:784 #3 0x555555988902 in read_attr_from_index attr.c:747 #4 0x555555988a1d in read_attr attr.c:800 #5 0x555555989b0c in bootstrap_attr_stack attr.c:882 #6 0x555555989b0c in prepare_attr_stack attr.c:917 #7 0x555555989b0c in collect_some_attrs attr.c:1112 #8 0x55555598b141 in git_check_attr attr.c:1126 #9 0x555555a13004 in convert_attrs convert.c:1311 #10 0x555555a95e04 in checkout_entry_ca entry.c:553 #11 0x555555d58bf6 in checkout_entry entry.h:42 #12 0x555555d58bf6 in check_updates unpack-trees.c:480 #13 0x555555d5eb55 in unpack_trees unpack-trees.c:2040 #14 0x555555785ab7 in checkout builtin/clone.c:724 #15 0x555555785ab7 in cmd_clone builtin/clone.c:1384 #16 0x55555572443c in run_builtin git.c:466 #17 0x55555572443c in handle_builtin git.c:721 #18 0x555555727872 in run_argv git.c:788 #19 0x555555727872 in cmd_main git.c:926 #20 0x555555721fa0 in main common-main.c:57 #21 0x7ffff73f1d09 in __libc_start_main ../csu/libc-start.c:308 #22 0x555555723f39 in _start (git+0x1cff39) 0x602000002552 is located 0 bytes to the right of 2-byte region [0x602000002550,0x602000002552) allocated by thread T0 here: #0 0x7ffff768c037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 #1 0x555555d7fff7 in xcalloc wrapper.c:150 #2 0x55555598815f in parse_attr_line attr.c:384 #3 0x55555598815f in handle_attr_line attr.c:660 #4 0x555555988902 in read_attr_from_index attr.c:784 #5 0x555555988902 in read_attr_from_index attr.c:747 #6 0x555555988a1d in read_attr attr.c:800 #7 0x555555989b0c in bootstrap_attr_stack attr.c:882 #8 0x555555989b0c in prepare_attr_stack attr.c:917 #9 0x555555989b0c in collect_some_attrs attr.c:1112 #10 0x55555598b141 in git_check_attr attr.c:1126 #11 0x555555a13004 in convert_attrs convert.c:1311 #12 0x555555a95e04 in checkout_entry_ca entry.c:553 #13 0x555555d58bf6 in checkout_entry entry.h:42 #14 0x555555d58bf6 in check_updates unpack-trees.c:480 #15 0x555555d5eb55 in unpack_trees unpack-trees.c:2040 #16 0x555555785ab7 in checkout builtin/clone.c:724 #17 0x555555785ab7 in cmd_clone builtin/clone.c:1384 #18 0x55555572443c in run_builtin git.c:466 #19 0x55555572443c in handle_builtin git.c:721 #20 0x555555727872 in run_argv git.c:788 #21 0x555555727872 in cmd_main git.c:926 #22 0x555555721fa0 in main common-main.c:57 #23 0x7ffff73f1d09 in __libc_start_main ../csu/libc-start.c:308 SUMMARY: AddressSanitizer: heap-buffer-overflow attr.c:393 in parse_attr_line Shadow bytes around the buggy address: 0x0c047fff8450: fa fa 00 02 fa fa 00 07 fa fa fd fd fa fa 00 00 0x0c047fff8460: fa fa 02 fa fa fa fd fd fa fa 00 06 fa fa 05 fa 0x0c047fff8470: fa fa fd fd fa fa 00 02 fa fa 06 fa fa fa 05 fa 0x0c047fff8480: fa fa 07 fa fa fa fd fd fa fa 00 01 fa fa 00 02 0x0c047fff8490: fa fa 00 03 fa fa 00 fa fa fa 00 01 fa fa 00 03 =>0x0c047fff84a0: fa fa 00 01 fa fa 00 02 fa fa[02]fa fa fa fa fa 0x0c047fff84b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff84c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff84d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff84e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff84f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc ==15062==ABORTING Fix this bug by using `size_t` instead to count the number of attributes so that this value cannot reasonably overflow without running out of memory before already. Reported-by: Markus Vervier <markus.vervier@x41-dsec.de> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 December 2022, 06:14:16 UTC
2455720 Patrick Steinhardt 01 December 2022, 14:45:23 UTC attr: fix integer overflow when parsing huge attribute names It is possible to trigger an integer overflow when parsing attribute names that are longer than 2^31 bytes because we assign the result of strlen(3P) to an `int` instead of to a `size_t`. This can lead to an abort in vsnprintf(3P) with the following reproducer: blob=$(perl -e 'print "A " . "B"x2147483648 . "\n"' | git hash-object -w --stdin) git update-index --add --cacheinfo 100644,$blob,.gitattributes git check-attr --all path BUG: strbuf.c:400: your vsnprintf is broken (returned -1) But furthermore, assuming that the attribute name is even longer than that, it can cause us to silently truncate the attribute and thus lead to wrong results. Fix this integer overflow by using a `size_t` instead. This fixes the silent truncation of attribute names, but it only partially fixes the BUG we hit: even though the initial BUG is fixed, we can still hit a BUG when parsing invalid attribute lines via `report_invalid_attr()`. This is due to an underlying design issue in vsnprintf(3P) which only knows to return an `int`, and thus it may always overflow with large inputs. This issue is benign though: the worst that can happen is that the error message is misreported to be either truncated or too long, but due to the buffer being NUL terminated we wouldn't ever do an out-of-bounds read here. Reported-by: Markus Vervier <markus.vervier@x41-dsec.de> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 December 2022, 06:14:16 UTC
8d0d48c Patrick Steinhardt 01 December 2022, 14:45:19 UTC attr: fix out-of-bounds read with huge attribute names There is an out-of-bounds read possible when parsing gitattributes that have an attribute that is 2^31+1 bytes long. This is caused due to an integer overflow when we assign the result of strlen(3P) to an `int`, where we use the wrapped-around value in a subsequent call to memcpy(3P). The following code reproduces the issue: blob=$(perl -e 'print "a" x 2147483649 . " attr"' | git hash-object -w --stdin) git update-index --add --cacheinfo 100644,$blob,.gitattributes git check-attr --all file AddressSanitizer:DEADLYSIGNAL ================================================================= ==8451==ERROR: AddressSanitizer: SEGV on unknown address 0x7f93efa00800 (pc 0x7f94f1f8f082 bp 0x7ffddb59b3a0 sp 0x7ffddb59ab28 T0) ==8451==The signal is caused by a READ memory access. #0 0x7f94f1f8f082 (/usr/lib/libc.so.6+0x176082) #1 0x7f94f2047d9c in __interceptor_strspn /usr/src/debug/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:752 #2 0x560e190f7f26 in parse_attr_line attr.c:375 #3 0x560e190f9663 in handle_attr_line attr.c:660 #4 0x560e190f9ddd in read_attr_from_index attr.c:769 #5 0x560e190f9f14 in read_attr attr.c:797 #6 0x560e190fa24e in bootstrap_attr_stack attr.c:867 #7 0x560e190fa4a5 in prepare_attr_stack attr.c:902 #8 0x560e190fb5dc in collect_some_attrs attr.c:1097 #9 0x560e190fb93f in git_all_attrs attr.c:1128 #10 0x560e18e6136e in check_attr builtin/check-attr.c:67 #11 0x560e18e61c12 in cmd_check_attr builtin/check-attr.c:183 #12 0x560e18e15993 in run_builtin git.c:466 #13 0x560e18e16397 in handle_builtin git.c:721 #14 0x560e18e16b2b in run_argv git.c:788 #15 0x560e18e17991 in cmd_main git.c:926 #16 0x560e190ae2bd in main common-main.c:57 #17 0x7f94f1e3c28f (/usr/lib/libc.so.6+0x2328f) #18 0x7f94f1e3c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349) #19 0x560e18e110e4 in _start ../sysdeps/x86_64/start.S:115 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/usr/lib/libc.so.6+0x176082) ==8451==ABORTING Fix this bug by converting the variable to a `size_t` instead. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 December 2022, 06:14:16 UTC
eb22e7d Patrick Steinhardt 01 December 2022, 14:45:15 UTC attr: fix overflow when upserting attribute with overly long name The function `git_attr_internal()` is called to upsert attributes into the global map. And while all callers pass a `size_t`, the function itself accepts an `int` as the attribute name's length. This can lead to an integer overflow in case the attribute name is longer than `INT_MAX`. Now this overflow seems harmless as the first thing we do is to call `attr_name_valid()`, and that function only succeeds in case all chars in the range of `namelen` match a certain small set of chars. We thus can't do an out-of-bounds read as NUL is not part of that set and all strings passed to this function are NUL-terminated. And furthermore, we wouldn't ever read past the current attribute name anyway due to the same reason. And if validation fails we will return early. On the other hand it feels fragile to rely on this behaviour, even more so given that we pass `namelen` to `FLEX_ALLOC_MEM()`. So let's instead just do the correct thing here and accept a `size_t` as line length. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 December 2022, 06:14:16 UTC
0d3507f Jiang Xin 25 November 2022, 09:59:54 UTC ci: install python on ubuntu Python is missing from the default ubuntu-22.04 runner image, which prevents git-p4 from working. To install python on ubuntu, we need to provide the correct package names: * On Ubuntu 18.04 (bionic), "/usr/bin/python2" is provided by the "python" package, and "/usr/bin/python3" is provided by the "python3" package. * On Ubuntu 20.04 (focal) and above, "/usr/bin/python2" is provided by the "python2" package which has a different name from bionic, and "/usr/bin/python3" is provided by "python3". Since the "ubuntu-latest" runner image has a higher version, its safe to use "python2" or "python3" package name. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 November 2022, 00:33:43 UTC
31a1952 Jiang Xin 25 November 2022, 09:59:53 UTC ci: use the same version of p4 on both Linux and macOS There would be a segmentation fault when running p4 v16.2 on ubuntu 22.04 which is the latest version of ubuntu runner image for github actions. By checking each version from [1], p4d version 21.1 and above can work properly on ubuntu 22.04. But version 22.x will break some p4 test cases. So p4 version 21.x is exactly the version we can use. With this update, the versions of p4 for Linux and macOS happen to be the same. So we can add the version number directly into the "P4WHENCE" variable, and reuse it in p4 installation for macOS. By removing the "LINUX_P4_VERSION" variable from "ci/lib.sh", the comment left above has nothing to do with p4, but still applies to git-lfs. Since we have a fixed version of git-lfs installed on Linux, we may have a different version on macOS. [1]: https://cdist2.perforce.com/perforce/ Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 November 2022, 00:32:56 UTC
4137c84 Jiang Xin 25 November 2022, 09:59:52 UTC ci: remove the pipe after "p4 -V" to catch errors When installing p4 as a dependency, we used to pipe output of "p4 -V" and "p4d -V" to validate the installation and output a condensed version information. But this would hide potential errors of p4 and would stop with an empty output. E.g.: p4d version 16.2 running on ubuntu 22.04 causes sigfaults, even before it produces any output. By removing the pipe after "p4 -V" and "p4d -V", we may get a verbose output, and stop immediately on errors because we have "set -e" in "ci/lib.sh". Since we won't look at these trace logs unless something fails, just including the raw output seems most sensible. Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 November 2022, 00:31:59 UTC
0178420 Jiang Xin 25 November 2022, 09:59:51 UTC github-actions: run gcc-8 on ubuntu-20.04 image GitHub starts to upgrade its runner image "ubuntu-latest" from version "ubuntu-20.04" to version "ubuntu-22.04". It will fail to find and install "gcc-8" package on the new runner image. Change some of the runner images from "ubuntu-latest" to "ubuntu-20.04" in order to install "gcc-8" as a dependency. The first revision of this patch tried to replace "$runs_on_pool" in "ci/*.sh" with a new "$runs_on_os" environment variable based on the "os" field in the matrix strategy. But these "os" fields in matrix strategies are obsolete legacies from commit [1] and commit [2], and are no longer useful. So remove these unused "os" fields. [1]: c08bb26010 (CI: rename the "Linux32" job to lower-case "linux32", 2021-11-23) [2]: 25715419bf (CI: don't run "make test" twice in one job, 2021-11-23) Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 November 2022, 00:31:12 UTC
e7e5c6f Junio C Hamano 27 October 2022, 22:24:23 UTC Downmerge a bit more for 2.38.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 October 2022, 22:24:23 UTC
40d2f93 Junio C Hamano 27 October 2022, 22:24:14 UTC Merge branch 'rs/archive-dedup-printf' into maint-2.38 Code simplification. * rs/archive-dedup-printf: archive: deduplicate verbose printing 27 October 2022, 22:24:14 UTC
4532cd8 Junio C Hamano 27 October 2022, 22:24:13 UTC Merge branch 'jh/struct-zero-init-with-older-clang' into maint-2.38 Work around older clang that warns against C99 zero initialization syntax for struct. * jh/struct-zero-init-with-older-clang: config.mak.dev: disable suggest braces error on old clang versions 27 October 2022, 22:24:13 UTC
92cd390 Junio C Hamano 27 October 2022, 22:24:13 UTC Merge branch 'rs/use-fspathncmp' into maint-2.38 Code clean-up. * rs/use-fspathncmp: dir: use fspathncmp() in pl_hashmap_cmp() 27 October 2022, 22:24:13 UTC
64de207 Junio C Hamano 27 October 2022, 22:24:13 UTC Merge branch 'rj/branch-edit-desc-unborn' into maint-2.38 "git branch --edit-description" on an unborh branch misleadingly said that no such branch exists, which has been corrected. * rj/branch-edit-desc-unborn: branch: description for non-existent branch errors 27 October 2022, 22:24:13 UTC
94f76c6 Junio C Hamano 27 October 2022, 22:24:13 UTC Merge branch 'pw/remove-rebase-p-test' into maint-2.38 Remove outdated test. * pw/remove-rebase-p-test: t3435: remove redundant test case 27 October 2022, 22:24:13 UTC
196b784 Junio C Hamano 27 October 2022, 22:24:13 UTC Merge branch 'jc/use-of-uc-in-log-messages' into maint-2.38 Clarify that "the sentence after <area>: prefix does not begin with a capital letter" rule applies only to the commit title. * jc/use-of-uc-in-log-messages: SubmittingPatches: use usual capitalization in the log message body 27 October 2022, 22:24:13 UTC
606c7e2 Junio C Hamano 27 October 2022, 22:24:12 UTC Merge branch 'jc/tmp-objdir' into maint-2.38 The code to clean temporary object directories (used for quarantine) tried to remove them inside its signal handler, which was a no-no. * jc/tmp-objdir: tmp-objdir: skip clean up when handling a signal 27 October 2022, 22:24:12 UTC
3cf20d1 Junio C Hamano 27 October 2022, 22:24:12 UTC Merge branch 'dd/document-runtime-prefix-better' into maint-2.38 Update comment in the Makefile about the RUNTIME_PREFIX config knob. * dd/document-runtime-prefix-better: Makefile: clarify runtime relative gitexecdir 27 October 2022, 22:24:12 UTC
cf649a3 Junio C Hamano 27 October 2022, 22:24:12 UTC Merge branch 'ab/unused-annotation' into maint-2.38 Compilation fix for ancient compilers. * ab/unused-annotation: git-compat-util.h: GCC deprecated message arg only in GCC 4.5+ 27 October 2022, 22:24:12 UTC
a9514e3 Junio C Hamano 27 October 2022, 22:24:11 UTC Merge branch 'tb/midx-repack-ignore-cruft-packs' into maint-2.38 "git multi-pack-index repack/expire" used to repack unreachable cruft into a new pack, which have been corrected. cf. <63a1c3d4-eff3-af10-4263-058c88e74594@github.com> * tb/midx-repack-ignore-cruft-packs: midx.c: avoid cruft packs with non-zero `repack --batch-size` midx.c: remove unnecessary loop condition midx.c: replace `xcalloc()` with `CALLOC_ARRAY()` midx.c: avoid cruft packs with `repack --batch-size=0` midx.c: prevent `expire` from removing the cruft pack Documentation/git-multi-pack-index.txt: clarify expire behavior Documentation/git-multi-pack-index.txt: fix typo 27 October 2022, 22:24:11 UTC
1b97c13 Junio C Hamano 27 October 2022, 22:24:11 UTC Merge branch 'so/diff-merges-cleanup' into maint-2.38 Code clean-up. * so/diff-merges-cleanup: diff-merges: clarify log.diffMerges documentation diff-merges: cleanup set_diff_merges() diff-merges: cleanup func_by_opt() 27 October 2022, 22:24:11 UTC
feba8be Junio C Hamano 27 October 2022, 22:24:11 UTC Merge branch 'rj/ref-filter-get-head-description-leakfix' into maint-2.38 Leakfix. * rj/ref-filter-get-head-description-leakfix: ref-filter.c: fix a leak in get_head_description 27 October 2022, 22:24:11 UTC
ded944f Junio C Hamano 27 October 2022, 22:24:09 UTC Merge branch 'jc/environ-docs' into maint-2.38 Documentation on various Boolean GIT_* environment variables have been clarified. * jc/environ-docs: environ: GIT_INDEX_VERSION affects not just a new repository environ: simplify description of GIT_INDEX_FILE environ: GIT_FLUSH should be made a usual Boolean environ: explain Boolean environment variables environ: document GIT_SSL_NO_VERIFY 27 October 2022, 22:24:09 UTC
86fa968 Jeff King 18 October 2022, 20:15:33 UTC Makefile: force -O0 when compiling with SANITIZE=leak Cherry pick commit d3775de0 (Makefile: force -O0 when compiling with SANITIZE=leak, 2022-10-18), as otherwise the leak checker at GitHub Actions CI seems to fail with a false positive. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 October 2022, 22:12:22 UTC
7d8dc5a Junio C Hamano 26 October 2022, 00:11:13 UTC Downmerge a handful of topics for 2.38.2 26 October 2022, 00:11:39 UTC
1f49b51 Junio C Hamano 26 October 2022, 00:11:39 UTC Merge branch 'jk/cleanup-callback-parameters' into maint-2.38 Code clean-up. * jk/cleanup-callback-parameters: attr: drop DEBUG_ATTR code commit: avoid writing to global in option callback multi-pack-index: avoid writing to global in option callback test-submodule: inline resolve_relative_url() function 26 October 2022, 00:11:39 UTC
28f9cd0 Junio C Hamano 26 October 2022, 00:11:39 UTC Merge branch 'rs/gc-pack-refs-simplify' into maint-2.38 Code clean-up. * rs/gc-pack-refs-simplify: gc: simplify maintenance_task_pack_refs() 26 October 2022, 00:11:39 UTC
b30a443 Junio C Hamano 26 October 2022, 00:11:38 UTC Merge branch 'nb/doc-mergetool-typofix' into maint-2.38 Typofix. * nb/doc-mergetool-typofix: mergetool.txt: typofix 'overwriten' -> 'overwritten' 26 October 2022, 00:11:38 UTC
553ea9d Junio C Hamano 26 October 2022, 00:11:38 UTC Merge branch 'jk/sequencer-missing-author-name-check' into maint-2.38 Typofix in code. * jk/sequencer-missing-author-name-check: sequencer: detect author name errors in read_author_script() 26 October 2022, 00:11:38 UTC
ff8d1ec Junio C Hamano 26 October 2022, 00:11:37 UTC Merge branch 'ds/bundle-uri-docfix' into maint-2.38 Doc formatting fix. * ds/bundle-uri-docfix: bundle-uri: fix technical doc issues 26 October 2022, 00:11:37 UTC
71220d8 Junio C Hamano 26 October 2022, 00:11:37 UTC Merge branch 'ab/test-malloc-with-sanitize-leak' into maint-2.38 Test fix. * ab/test-malloc-with-sanitize-leak: test-lib: have SANITIZE=leak imply TEST_NO_MALLOC_CHECK 26 October 2022, 00:11:37 UTC
3ae0094 Junio C Hamano 26 October 2022, 00:11:37 UTC Merge branch 'rs/bisect-start-leakfix' into maint-2.38 Code clean-up that results in plugging a leak. * rs/bisect-start-leakfix: bisect--helper: plug strvec leak 26 October 2022, 00:11:37 UTC
1155c8e Junio C Hamano 26 October 2022, 00:11:37 UTC Merge branch 'jc/branch-description-unset' into maint-2.38 "GIT_EDITOR=: git branch --edit-description" resulted in failure, which has been corrected. * jc/branch-description-unset: branch: do not fail a no-op --edit-desc 26 October 2022, 00:11:37 UTC
48b754d Junio C Hamano 26 October 2022, 00:11:35 UTC Merge branch 'pw/ssh-sign-report-errors' into maint-2.38 The codepath to sign learned to report errors when it fails to read from "ssh-keygen". * pw/ssh-sign-report-errors: ssh signing: return an error when signature cannot be read 26 October 2022, 00:11:35 UTC
3694b38 Junio C Hamano 26 October 2022, 00:11:35 UTC Merge branch 'pw/mailinfo-b-fix' into maint-2.38 Fix a logic in "mailinfo -b" that miscomputed the length of a substring, which lead to an out-of-bounds access. * pw/mailinfo-b-fix: mailinfo -b: fix an out of bounds access 26 October 2022, 00:11:35 UTC
4dccc00 Junio C Hamano 26 October 2022, 00:11:35 UTC Merge branch 'rs/test-httpd-in-C-locale' into maint-2.38 Force C locale while running tests around httpd to make sure we can find expected error messages in the log. * rs/test-httpd-in-C-locale: t/lib-httpd: pass LANG and LC_ALL to Apache 26 October 2022, 00:11:35 UTC
bcf22f2 Junio C Hamano 26 October 2022, 00:11:34 UTC Merge branch 'js/merge-ort-in-read-only-repo' into maint-2.38 In read-only repositories, "git merge-tree" tried to come up with a merge result tree object, which it failed (which is not wrong) and led to a segfault (which is bad), which has been corrected. * js/merge-ort-in-read-only-repo: merge-ort: return early when failing to write a blob merge-ort: fix segmentation fault in read-only repositories 26 October 2022, 00:11:34 UTC
7f8a6ca Junio C Hamano 26 October 2022, 00:11:34 UTC Merge branch 'ja/rebase-i-avoid-amending-self' into maint-2.38 "git rebase -i" can mistakenly attempt to apply a fixup to a commit itself, which has been corrected. * ja/rebase-i-avoid-amending-self: sequencer: avoid dropping fixup commit that targets self via commit-ish 26 October 2022, 00:11:34 UTC
cf96b39 Junio C Hamano 26 October 2022, 00:11:33 UTC Merge branch 'jk/fsck-on-diet' into maint-2.38 "git fsck" failed to release contents of tree objects already used from the memory, which has been fixed. * jk/fsck-on-diet: parse_object_buffer(): respect save_commit_buffer fsck: turn off save_commit_buffer fsck: free tree buffers after walking unreachable objects 26 October 2022, 00:11:33 UTC
1655ac8 Junio C Hamano 26 October 2022, 00:11:33 UTC Merge branch 'ah/fsmonitor-daemon-usage-non-l10n' into maint-2.38 Fix messages incorrectly marked for translation. * ah/fsmonitor-daemon-usage-non-l10n: fsmonitor--daemon: don't translate literal commands 26 October 2022, 00:11:33 UTC
0d5d929 Junio C Hamano 26 October 2022, 00:11:33 UTC Merge branch 'jk/clone-allow-bare-and-o-together' into maint-2.38 "git clone" did not like to see the "--bare" and the "--origin" options used together without a good reason. * jk/clone-allow-bare-and-o-together: clone: allow "--bare" with "-o" 26 October 2022, 00:11:33 UTC
665d7e0 Junio C Hamano 26 October 2022, 00:11:32 UTC Merge branch 'jk/remote-rename-without-fetch-refspec' into maint-2.38 "git remote rename" failed to rename a remote without fetch refspec, which has been corrected. * jk/remote-rename-without-fetch-refspec: remote: handle rename of remote without fetch refspec 26 October 2022, 00:11:32 UTC
457f863 Junio C Hamano 26 October 2022, 00:11:32 UTC Merge branch 'vd/fix-unaligned-read-index-v4' into maint-2.38 The codepath that reads from the index v4 had unaligned memory accesses, which has been corrected. * vd/fix-unaligned-read-index-v4: read-cache: avoid misaligned reads in index v4 26 October 2022, 00:11:32 UTC
c72f2fe Junio C Hamano 26 October 2022, 00:11:32 UTC Merge branch 'ab/coding-guidelines-c99' into maint-2.38 Update CodingGuidelines to clarify what features to use and avoid in C99. * ab/coding-guidelines-c99: CodingGuidelines: recommend against unportable C99 struct syntax CodingGuidelines: mention C99 features we can't use CodingGuidelines: allow declaring variables in for loops CodingGuidelines: mention dynamic C99 initializer elements CodingGuidelines: update for C99 26 October 2022, 00:11:32 UTC
438c2f8 Ævar Arnfjörð Bjarmason 10 October 2022, 20:38:00 UTC CodingGuidelines: recommend against unportable C99 struct syntax Per 33665d98e6b (reftable: make assignments portable to AIX xlc v12.01, 2022-03-28) forms like ".a.b = *c" can be replaced by using ".a = { .b = *c }" instead. We'll probably allow these sooner than later, but since the workaround is trivial let's note it among the C99 features we'd like to hold off on for now. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 October 2022, 15:55:01 UTC
e3733b6 René Scharfe 11 October 2022, 09:29:38 UTC archive: deduplicate verbose printing 94bc671a1f (Add directory pattern matching to attributes, 2012-12-08) moved the code for adding the trailing slash to names of directories and submodules up. This left both branches of the if statement starting with the same conditional fprintf call. Deduplicate it. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 October 2022, 15:35:10 UTC
d7d850e Ævar Arnfjörð Bjarmason 10 October 2022, 20:37:59 UTC CodingGuidelines: mention C99 features we can't use The C99 section of the CodingGuidelines is a good overview of what we can use, but is sorely lacking in what we can't use. Something that comes up occasionally is the portability of %z. Per [1] we couldn't use it for the longest time due to MSVC not supporting it, but nowadays by requiring C99 we rely on the MSVC version that does, but we can't use it yet because a C library that MinGW uses doesn't support it. 1. https://lore.kernel.org/git/a67e0fd8-4a14-16c9-9b57-3430440ef93c@gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 October 2022, 20:41:12 UTC
82dd01d Ævar Arnfjörð Bjarmason 10 October 2022, 20:37:58 UTC CodingGuidelines: allow declaring variables in for loops Since 44ba10d6712 (revision: use C99 declaration of variable in for() loop, 2021-11-14) released with v2.35.0 we've had a variable declared with in a for loop. Since then we've had inadvertent follow-ups to that with at least cb2607759e2 (merge-ort: store more specific conflict information, 2022-06-18) released with v2.38.0. As November 2022 is within the window of this upcoming release, let's update the guideline to allow this. We can have the promised "revisit" discussion while this patch cooks, and drop it if it turns out that it is still premature, which is not expected to happen at this moment. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 October 2022, 20:41:11 UTC
442c27d Ævar Arnfjörð Bjarmason 10 October 2022, 20:37:57 UTC CodingGuidelines: mention dynamic C99 initializer elements The first use of variables in initializer elements appears to have been 2b6854c863a (Cleanup variables in cat-file, 2007-04-21) released with v1.5.2. Some of those caused portability issues, and e.g. that "cat-file" use was changed in 66dbfd55e38 (Rewrite dynamic structure initializations to runtime assignment, 2010-05-14) which went out with v1.7.2. But curiously 66dbfd55e38 missed some of them, e.g. an archive.c use added in d5f53d6d6f2 (archive: complain about path specs that don't match anything, 2009-12-12), and another one in merge-index.c (later builtin/merge-index.c) in 0077138cd9d (Simplify some instances of run_command() by using run_command_v_opt()., 2009-06-08). As far as I can tell there's been no point since 2b6854c863a in 2007 where a compiler that didn't support this has been able to compile git. Presumably 66dbfd55e38 was an attempt to make headway with wider portability that ultimately wasn't completed. In any case, we are thoroughly reliant on this syntax at this point, so let's update the guidelines, see https://lore.kernel.org/git/xmqqy1tunjgp.fsf@gitster.g/ for the initial discussion. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 October 2022, 20:41:11 UTC
e88a2d0 Ævar Arnfjörð Bjarmason 10 October 2022, 20:37:56 UTC CodingGuidelines: update for C99 Since 7bc341e21b5 (git-compat-util: add a test balloon for C99 support, 2021-12-01) we've had a hard dependency on C99, but the prose in CodingGuidelines was written under the assumption that we were using C89 with a few C99 features. As the updated prose notes we'd still like to hold off on novel C99 features, but let's make it clear that we target that C version, and then enumerate new C99 features that are safe to use. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 October 2022, 20:41:11 UTC
a677d3c Phillip Wood 10 October 2022, 09:45:06 UTC t3435: remove redundant test case rebase --preserve-merges no longer exists so there is no point in carrying this failing test case. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 October 2022, 18:18:18 UTC
54795d3 Jeff Hostetler 10 October 2022, 15:39:00 UTC config.mak.dev: disable suggest braces error on old clang versions Add the "-Wno-missing-braces" option when building with an old version of clang to suppress the "suggest braces around initialization" error in developer mode. For example, using an old version of clang gives the following errors (when in DEVELOPER=1 mode): $ make builtin/merge-file.o CC builtin/merge-file.o builtin/merge-file.c:29:23: error: suggest braces around initialization \ of subobject [-Werror,-Wmissing-braces] mmfile_t mmfs[3] = { 0 }; ^ {} builtin/merge-file.c:31:20: error: suggest braces around initialization \ of subobject [-Werror,-Wmissing-braces] xmparam_t xmp = { 0 }; ^ {} 2 errors generated. This example compiles without error/warning with updated versions of clang. Since this is an obsolete error, use the -Wno-missing-braces option to silence the warning when using an older compiler. This avoids the need to update the code to use "{{0}}" style initializations. Upstream clang version 8 has the problem. It was fixed in version 9. The version of clang distributed by Apple with XCode has its own unique set of version numbers. Apple clang version 11 has the problem. It was fixed in version 12. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 October 2022, 18:15:31 UTC
back to top