1f010d6bdf
We presently use the ".txt" extension for our AsciiDoc files. While not wrong, most editors do not associate this extension with AsciiDoc, meaning that contributors don't get automatic editor functionality that could be useful, such as syntax highlighting and prose linting. It is much more common to use the ".adoc" extension for AsciiDoc files, since this helps editors automatically detect files and also allows various forges to provide rich (HTML-like) rendering. Let's do that here, renaming all of the files and updating the includes where relevant. Adjust the various build scripts and makefiles to use the new extension as well. Note that this should not result in any user-visible changes to the documentation. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
66 lines
2.5 KiB
Plaintext
66 lines
2.5 KiB
Plaintext
Git 2.37.4 Release Notes
|
|
========================
|
|
|
|
This primarily is to backport various fixes accumulated on the 'master'
|
|
front since 2.37.3, and also includes the same security fixes as in
|
|
v2.30.6.
|
|
|
|
Fixes since v2.37.3
|
|
-------------------
|
|
|
|
* CVE-2022-39253:
|
|
When relying on the `--local` clone optimization, Git dereferences
|
|
symbolic links in the source repository before creating hardlinks
|
|
(or copies) of the dereferenced link in the destination repository.
|
|
This can lead to surprising behavior where arbitrary files are
|
|
present in a repository's `$GIT_DIR` when cloning from a malicious
|
|
repository.
|
|
|
|
Git will no longer dereference symbolic links via the `--local`
|
|
clone mechanism, and will instead refuse to clone repositories that
|
|
have symbolic links present in the `$GIT_DIR/objects` directory.
|
|
|
|
Additionally, the value of `protocol.file.allow` is changed to be
|
|
"user" by default.
|
|
|
|
Credit for finding CVE-2022-39253 goes to Cory Snider of Mirantis.
|
|
The fix was authored by Taylor Blau, with help from Johannes
|
|
Schindelin.
|
|
|
|
* CVE-2022-39260:
|
|
An overly-long command string given to `git shell` can result in
|
|
overflow in `split_cmdline()`, leading to arbitrary heap writes and
|
|
remote code execution when `git shell` is exposed and the directory
|
|
`$HOME/git-shell-commands` exists.
|
|
|
|
`git shell` is taught to refuse interactive commands that are
|
|
longer than 4MiB in size. `split_cmdline()` is hardened to reject
|
|
inputs larger than 2GiB.
|
|
|
|
Credit for finding CVE-2022-39260 goes to Kevin Backhouse of
|
|
GitHub. The fix was authored by Kevin Backhouse, Jeff King, and
|
|
Taylor Blau.
|
|
|
|
* An earlier optimization discarded a tree-object buffer that is
|
|
still in use, which has been corrected.
|
|
|
|
* Fix deadlocks between main Git process and subprocess spawned via
|
|
the pipe_command() API, that can kill "git add -p" that was
|
|
reimplemented in C recently.
|
|
|
|
* xcalloc(), imitating calloc(), takes "number of elements of the
|
|
array", and "size of a single element", in this order. A call that
|
|
does not follow this ordering has been corrected.
|
|
|
|
* The preload-index codepath made copies of pathspec to give to
|
|
multiple threads, which were left leaked.
|
|
|
|
* Update the version of Ubuntu used for GitHub Actions CI from 18.04
|
|
to 22.04.
|
|
|
|
* The auto-stashed local changes created by "git merge --autostash"
|
|
was mixed into a conflicted state left in the working tree, which
|
|
has been corrected.
|
|
|
|
Also contains other minor documentation updates and code clean-ups.
|