git/t, branch v2.35.0

Merge branch 'ab/checkout-branch-info-leakfix'

2022-01-24T17:14:46Z

We added an unrelated sanity checking that leads to a BUG() while plugging a leak, which triggered in a repository with symrefs in the local branch namespace that point at a ref outside. Partially revert the change to avoid triggering the BUG(). * ab/checkout-branch-info-leakfix: checkout: avoid BUG() when hitting a broken repository

checkout: avoid BUG() when hitting a broken repository

2022-01-22T01:04:50Z

When 9081a421 (checkout: fix "branch info" memory leaks, 2021-11-16) cleaned up existing memory leaks, we added an unrelated sanity check to ensure that a local branch is truly local and not a symref to elsewhere that dies with BUG() otherwise. This was misguided in two ways. First of all, such a tightening did not belong to a leak-fix patch. And the condition it detected was *not* a bug in our program but a problem in user data, where warning() or die() would have been more appropriate. As the condition is not fatal (the result of computing the local branch name in the code that is involved in the faulty check is only used as a textual label for the commit), let's revert the code to the original state, i.e. strip "refs/heads/" to compute the local branch name if possible, and otherwise leave it NULL. The consumer of the information in merge_working_tree() is prepared to see NULL in there and act accordingly. cf. https://bugzilla.redhat.com/show_bug.cgi?id=2042920 Reported-by: Petr Šplíchal Reported-by: Todd Zullinger Helped-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'js/t1450-making-it-writable-does-not-need-full-posixperm'

2022-01-14T23:25:15Z

Test fix. * js/t1450-making-it-writable-does-not-need-full-posixperm: t1450-fsck: exec-bit is not needed to make loose object writable

t1450-fsck: exec-bit is not needed to make loose object writable

2022-01-13T20:36:12Z

A test case wants to append stuff to a loose object file to ensure that this kind of corruption is detected. To make a read-only loose object file writable with chmod, it is not necessary to also make it executable. Replace the bitmask 755 with the instruction +w to request only the write bit and to also heed the umask. And get rid of a POSIXPERM prerequisite, which is unnecessary for the test. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano

Merge branch 'fs/gpg-unknown-key-test-fix'

2022-01-12T23:11:42Z

Test simplification. * fs/gpg-unknown-key-test-fix: t/gpg: simplify test for unknown key

Merge branch 'ma/windows-dynload-fix'

2022-01-12T23:11:41Z

Fix calling dynamically loaded functions on Windows. * ma/windows-dynload-fix: lazyload: use correct calling conventions

Merge branch 'fs/ssh-signing-key-lifetime'

2022-01-12T23:11:41Z

"git merge $signed_tag" started to drop the tag message from the default merge message it uses by accident, which has been corrected. * fs/ssh-signing-key-lifetime: fmt-merge-msg: prevent use-after-free with signed tags

t/gpg: simplify test for unknown key

2022-01-12T19:21:22Z

To test for a key that is completely unknown to the keyring we need one to sign the commit with. This was done by generating a new key and not add it into the keyring. To avoid the key generation overhead and problems where GPG did hang in CI during it, switch GNUPGHOME to the empty $GNUPGHOME_NOT_USED instead, therefore making all used keys unknown for this single `verify-commit` call. Reported-by: Ævar Arnfjörð Bjarmason Signed-off-by: Fabian Stelzer Reviewed-by: Taylor Blau Signed-off-by: Junio C Hamano

fmt-merge-msg: prevent use-after-free with signed tags

2022-01-10T21:57:40Z

When merging a signed tag, fmt_merge_msg_sigs() is responsible for populating the body of the merge message with the names of the signed tags, their signatures, and the validity of those signatures. In 02769437e1 (ssh signing: use sigc struct to pass payload, 2021-12-09), check_signature() was taught to pass the object payload via the sigc struct instead of passing the payload buffer separately. In effect, 02769437e1 causes buf, and sigc.payload to point at the same region in memory. This causes a problem for fmt_tag_signature(), which wants to read from this location, since it is freed beforehand by signature_check_clear() (which frees it via sigc's `payload` member). That makes the subsequent use in fmt_tag_signature() a use-after-free. As a result, merge messages did not contain the body of any signed tags. Luckily, they tend not to contain garbage, either, since the result of strstr()-ing the object buffer in fmt_tag_signature() is guarded: const char *tag_body = strstr(buf, "\n\n"); if (tag_body) { tag_body += 2; strbuf_add(tagbuf, tag_body, buf + len - tag_body); } Unfortunately, the tests in t6200 did not catch this at the time because they do not search for the body of signed tags in fmt-merge-msg's output. Resolve this by waiting to call signature_check_clear() until after its contents can be safely discarded. Harden ourselves against any future regressions in this area by making sure we can find signed tag messages in the output of fmt-merge-msg, too. Reported-by: Linus Torvalds Signed-off-by: Taylor Blau Signed-off-by: Junio C Hamano

Merge branch 'en/stash-df-fix'

2022-01-10T19:52:57Z

"git stash apply" forgot to attempt restoring untracked files when it failed to restore changes to tracked ones. * en/stash-df-fix: stash: do not return before restoring untracked files