swh:1:snp:6df5a50b8107b6bbe1e51d0239d816a7503c536a

sort by:
Revision Author Date Message Commit Date
f2eed22 Git 2.34.4 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 June 2022, 10:35:49 UTC
378eade Sync with 2.33.4 * maint-2.33: Git 2.33.4 Git 2.32.3 Git 2.31.4 Git 2.30.5 setup: tighten ownership checks post CVE-2022-24765 git-compat-util: allow root to access both SUDO_UID and root owned t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo 23 June 2022, 10:35:47 UTC
80c525c Git 2.33.4 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 June 2022, 10:35:41 UTC
eebfde3 Sync with 2.32.3 * maint-2.32: Git 2.32.3 Git 2.31.4 Git 2.30.5 setup: tighten ownership checks post CVE-2022-24765 git-compat-util: allow root to access both SUDO_UID and root owned t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo 23 June 2022, 10:35:38 UTC
656d9a2 Git 2.32.3 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 June 2022, 10:35:32 UTC
fc0c773 Sync with 2.31.4 * maint-2.31: Git 2.31.4 Git 2.30.5 setup: tighten ownership checks post CVE-2022-24765 git-compat-util: allow root to access both SUDO_UID and root owned t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo 23 June 2022, 10:35:30 UTC
5b1c746 Git 2.31.4 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 June 2022, 10:35:25 UTC
2f8809f Sync with 2.30.5 * maint-2.30: Git 2.30.5 setup: tighten ownership checks post CVE-2022-24765 git-compat-util: allow root to access both SUDO_UID and root owned t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo 23 June 2022, 10:35:23 UTC
88b7be6 Git 2.30.5 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 June 2022, 10:31:05 UTC
3b0bf27 setup: tighten ownership checks post CVE-2022-24765 8959555cee7 (setup_git_directory(): add an owner check for the top-level directory, 2022-03-02), adds a function to check for ownership of repositories using a directory that is representative of it, and ways to add exempt a specific repository from said check if needed, but that check didn't account for owership of the gitdir, or (when used) the gitfile that points to that gitdir. An attacker could create a git repository in a directory that they can write into but that is owned by the victim to work around the fix that was introduced with CVE-2022-24765 to potentially run code as the victim. An example that could result in privilege escalation to root in *NIX would be to set a repository in a shared tmp directory by doing (for example): $ git -C /tmp init To avoid that, extend the ensure_valid_ownership function to be able to check for all three paths. This will have the side effect of tripling the number of stat() calls when a repository is detected, but the effect is expected to be likely minimal, as it is done only once during the directory walk in which Git looks for a repository. Additionally make sure to resolve the gitfile (if one was used) to find the relevant gitdir for checking. While at it change the message printed on failure so it is clear we are referring to the repository by its worktree (or gitdir if it is bare) and not to a specific directory. Helped-by: Junio C Hamano <junio@pobox.com> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> 23 June 2022, 10:31:05 UTC
b779214 Merge branch 'cb/path-owner-check-with-sudo' With a recent update to refuse access to repositories of other people by default, "sudo make install" and "sudo git describe" stopped working. This series intends to loosen it while keeping the safety. * cb/path-owner-check-with-sudo: t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 June 2022, 10:31:04 UTC
6b11e3d git-compat-util: allow root to access both SUDO_UID and root owned Previous changes introduced a regression which will prevent root for accessing repositories owned by thyself if using sudo because SUDO_UID takes precedence. Loosen that restriction by allowing root to access repositories owned by both uid by default and without having to add a safe.directory exception. A previous workaround that was documented in the tests is no longer needed so it has been removed together with its specially crafted prerequisite. Helped-by: Johanness Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 June 2022, 21:03:08 UTC
b9063af t0034: add negative tests and allow git init to mostly work under sudo Add a support library that provides one function that can be used to run a "scriplet" of commands through sudo and that helps invoking sudo in the slightly awkward way that is required to ensure it doesn't block the call (if shell was allowed as tested in the prerequisite) and it doesn't run the command through a different shell than the one we intended. Add additional negative tests as suggested by Junio and that use a new workspace that is owned by root. Document a regression that was introduced by previous commits where root won't be able anymore to access directories they own unless SUDO_UID is removed from their environment. The tests document additional ways that this new restriction could be worked around and the documentation explains why it might be instead considered a feature, but a "fix" is planned for a future change. Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Phillip Wood <phillip.wood123@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 May 2022, 01:12:23 UTC
ae9abbb git-compat-util: avoid failing dir ownership checks if running privileged bdc77d1d685 (Add a function to determine whether a path is owned by the current user, 2022-03-02) checks for the effective uid of the running process using geteuid() but didn't account for cases where that user was root (because git was invoked through sudo or a compatible tool) and the original uid that repository trusted for its config was no longer known, therefore failing the following otherwise safe call: guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty [sudo] password for guy: fatal: unsafe repository ('/home/guy/Software/uncrustify' is owned by someone else) Attempt to detect those cases by using the environment variables that those tools create to keep track of the original user id, and do the ownership check using that instead. This assumes the environment the user is running on after going privileged can't be tampered with, and also adds code to restrict that the new behavior only applies if running as root, therefore keeping the most common case, which runs unprivileged, from changing, but because of that, it will miss cases where sudo (or an equivalent) was used to change to another unprivileged user or where the equivalent tool used to raise privileges didn't track the original id in a sudo compatible way. Because of compatibility with sudo, the code assumes that uid_t is an unsigned integer type (which is not required by the standard) but is used that way in their codebase to generate SUDO_UID. In systems where uid_t is signed, sudo might be also patched to NOT be unsigned and that might be able to trigger an edge case and a bug (as described in the code), but it is considered unlikely to happen and even if it does, the code would just mostly fail safely, so there was no attempt either to detect it or prevent it by the code, which is something that might change in the future, based on expected user feedback. Reported-by: Guy Maurel <guy.j@maurel.de> Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Randall Becker <rsbecker@nexbridge.com> Helped-by: Phillip Wood <phillip.wood123@gmail.com> Suggested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 May 2022, 01:12:23 UTC
5f1a3fe t: regression git needs safe.directory when using sudo Originally reported after release of v2.35.2 (and other maint branches) for CVE-2022-24765 and blocking otherwise harmless commands that were done using sudo in a repository that was owned by the user. Add a new test script with very basic support to allow running git commands through sudo, so a reproduction could be implemented and that uses only `git status` as a proxy of the issue reported. Note that because of the way sudo interacts with the system, a much more complete integration with the test framework will require a lot more work and that was therefore intentionally punted for now. The current implementation requires the execution of a special cleanup function which should always be kept as the last "test" or otherwise the standard cleanup functions will fail because they can't remove the root owned directories that are used. This also means that if failures are found while running, the specifics of the failure might not be kept for further debugging and if the test was interrupted, it will be necessary to clean the working directory manually before restarting by running: $ sudo rm -rf trash\ directory.t0034-root-safe-directory/ The test file also uses at least one initial "setup" test that creates a parallel execution directory under the "root" sub directory, which should be used as top level directory for all repositories that are used in this test file. Unlike all other tests the repository provided by the test framework should go unused. Special care should be taken when invoking commands through sudo, since the environment is otherwise independent from what the test framework setup and might have changed the values for HOME, SHELL and dropped several relevant environment variables for your test. Indeed `git status` was used as a proxy because it doesn't even require commits in the repository to work and usually doesn't require much from the environment to run, but a future patch will add calls to `git init` and that will fail to honor the default branch name, unless that setting is NOT provided through an environment variable (which means even a CI run could fail that test if enabled incorrectly). A new SUDO prerequisite is provided that does some sanity checking to make sure the sudo command that will be used allows for passwordless execution as root without restrictions and doesn't mess with git's execution path. This matches what is provided by the macOS agents that are used as part of GitHub actions and probably nowhere else. Most of those characteristics make this test mostly only suitable for CI, but it might be executed locally if special care is taken to provide for all of them in the local configuration and maybe making use of the sudo credential cache by first invoking sudo, entering your password if needed, and then invoking the test with: $ GIT_TEST_ALLOW_SUDO=YES ./t0034-root-safe-directory.sh If it fails to run, then it means your local setup wouldn't work for the test because of the configuration sudo has or other system settings, and things that might help are to comment out sudo's secure_path config, and make sure that the account you are using has no restrictions on the commands it can run through sudo, just like is provided for the user in the CI. For example (assuming a username of marta for you) something probably similar to the following entry in your /etc/sudoers (or equivalent) file: marta ALL=(ALL:ALL) NOPASSWD: ALL Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Phillip Wood <phillip.wood123@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 May 2022, 01:12:23 UTC
2f0dde7 Git 2.34.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 April 2022, 22:21:31 UTC
1f65dd6 Git 2.33.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 April 2022, 22:21:28 UTC
1530434 Git 2.32.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 April 2022, 22:21:26 UTC
09f66d6 Git 2.31.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 April 2022, 22:21:08 UTC
17083c7 Git 2.30.4 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 April 2022, 20:31:29 UTC
0f85c4a setup: opt-out of check with safe.directory=* With the addition of the safe.directory in 8959555ce (setup_git_directory(): add an owner check for the top-level directory, 2022-03-02) released in v2.35.2, we are receiving feedback from a variety of users about the feature. Some users have a very large list of shared repositories and find it cumbersome to add this config for every one of them. In a more difficult case, certain workflows involve running Git commands within containers. The container boundary prevents any global or system config from communicating `safe.directory` values from the host into the container. Further, the container almost always runs as a different user than the owner of the directory in the host. To simplify the reactions necessary for these users, extend the definition of the safe.directory config value to include a possible '*' value. This value implies that all directories are safe, providing a single setting to opt-out of this protection. Note that an empty assignment of safe.directory clears all previous values, and this is already the case with the "if (!value || !*value)" condition. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 April 2022, 19:42:51 UTC
bb50ec3 setup: fix safe.directory key not being checked It seems that nothing is ever checking to make sure the safe directories in the configs actually have the key safe.directory, so some unrelated config that has a value with a certain directory would also make it a safe directory. Signed-off-by: Matheus Valadares <me@m28.io> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 April 2022, 19:42:51 UTC
e47363e t0033: add tests for safe.directory It is difficult to change the ownership on a directory in our test suite, so insert a new GIT_TEST_ASSUME_DIFFERENT_OWNER environment variable to trick Git into thinking we are in a differently-owned directory. This allows us to test that the config is parsed correctly. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 April 2022, 19:42:49 UTC
4d0b43a Git 2.34.2 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 March 2022, 23:31:36 UTC
93fbff0 Sync with 2.33.2 * maint-2.33: Git 2.33.2 Git 2.32.1 Git 2.31.2 GIT-VERSION-GEN: bump to v2.33.1 Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user 23 March 2022, 23:31:36 UTC
87ed4fc Git 2.33.2 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 March 2022, 23:31:32 UTC
303b876 Sync with 2.32.1 * maint-2.32: Git 2.32.1 Git 2.31.2 Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user 23 March 2022, 23:31:32 UTC
9bcd7a8 Git 2.32.1 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 March 2022, 23:31:29 UTC
201b0c7 Sync with 2.31.2 * maint-2.31: Git 2.31.2 Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user 23 March 2022, 23:31:28 UTC
44de39c Git 2.31.2 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 March 2022, 23:24:29 UTC
6a2381a Sync with 2.30.3 * maint-2.30: Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user 23 March 2022, 23:24:29 UTC
cb95038 Git 2.30.3 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 March 2022, 23:22:17 UTC
fdcad5a Fix `GIT_CEILING_DIRECTORIES` with `C:\` and the likes When determining the length of the longest ancestor of a given path with respect to to e.g. `GIT_CEILING_DIRECTORIES`, we special-case the root directory by returning 0 (i.e. we pretend that the path `/` does not end in a slash by virtually stripping it). That is the correct behavior because when normalizing paths, the root directory is special: all other directory paths have their trailing slash stripped, but not the root directory's path (because it would become the empty string, which is not a legal path). However, this special-casing of the root directory in `longest_ancestor_length()` completely forgets about Windows-style root directories, e.g. `C:\`. These _also_ get normalized with a trailing slash (because `C:` would actually refer to the current directory on that drive, not necessarily to its root directory). In fc56c7b34b (mingw: accomodate t0060-path-utils for MSYS2, 2016-01-27), we almost got it right. We noticed that `longest_ancestor_length()` expects a slash _after_ the matched prefix, and if the prefix already ends in a slash, the normalized path won't ever match and -1 is returned. But then that commit went astray: The correct fix is not to adjust the _tests_ to expect an incorrect -1 when that function is fed a prefix that ends in a slash, but instead to treat such a prefix as if the trailing slash had been removed. Likewise, that function needs to handle the case where it is fed a path that ends in a slash (not only a prefix that ends in a slash): if it matches the prefix (plus trailing slash), we still need to verify that the path does not end there, otherwise the prefix is not actually an ancestor of the path but identical to it (and we need to return -1 in that case). With these two adjustments, we no longer need to play games in t0060 where we only add `$rootoff` if the passed prefix is different from the MSYS2 pseudo root, instead we also add it for the MSYS2 pseudo root itself. We do have to be careful to skip that logic entirely for Windows paths, though, because they do are not subject to that MSYS2 pseudo root treatment. This patch fixes the scenario where a user has set `GIT_CEILING_DIRECTORIES=C:\`, which would be ignored otherwise. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 March 2022, 23:21:08 UTC
8959555 setup_git_directory(): add an owner check for the top-level directory It poses a security risk to search for a git directory outside of the directories owned by the current user. For example, it is common e.g. in computer pools of educational institutes to have a "scratch" space: a mounted disk with plenty of space that is regularly swiped where any authenticated user can create a directory to do their work. Merely navigating to such a space with a Git-enabled `PS1` when there is a maliciously-crafted `/scratch/.git/` can lead to a compromised account. The same holds true in multi-user setups running Windows, as `C:\` is writable to every authenticated user by default. To plug this vulnerability, we stop Git from accepting top-level directories owned by someone other than the current user. We avoid looking at the ownership of each and every directories between the current and the top-level one (if there are any between) to avoid introducing a performance bottleneck. This new default behavior is obviously incompatible with the concept of shared repositories, where we expect the top-level directory to be owned by only one of its legitimate users. To re-enable that use case, we add support for adding exceptions from the new default behavior via the config setting `safe.directory`. The `safe.directory` config setting is only respected in the system and global configs, not from repository configs or via the command-line, and can have multiple values to allow for multiple shared repositories. We are particularly careful to provide a helpful message to any user trying to use a shared repository. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 21 March 2022, 12:16:26 UTC
bdc77d1 Add a function to determine whether a path is owned by the current user This function will be used in the next commit to prevent `setup_git_directory()` from discovering a repository in a directory that is owned by someone other than the current user. Note: We cannot simply use `st.st_uid` on Windows just like we do on Linux and other Unix-like platforms: according to https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions this field is always zero on Windows (because Windows' idea of a user ID does not fit into a single numerical value). Therefore, we have to do something a little involved to replicate the same functionality there. Also note: On Windows, a user's home directory is not actually owned by said user, but by the administrator. For all practical purposes, it is under the user's control, though, therefore we pretend that it is owned by the user. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 21 March 2022, 12:16:26 UTC
2a9a586 Merge branch 'cb/mingw-gmtime-r' Build fix on Windows. * cb/mingw-gmtime-r: mingw: avoid fallback for {local,gm}time_r() Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 March 2022, 11:52:12 UTC
6e7ad1e mingw: avoid fallback for {local,gm}time_r() mingw-w64's pthread_unistd.h had a bug that mistakenly (because there is no support for the *lockfile() functions required[1]) defined _POSIX_THREAD_SAFE_FUNCTIONS and that was being worked around since 3ecd153a3b (compat/mingw: support MSys2-based MinGW build, 2016-01-14). The bug was fixed in winphtreads, but as a side effect, leaves the reentrant functions from time.h no longer visible and therefore breaks the build. Since the intention all along was to avoid using the fallback functions, formalize the use of POSIX by setting the corresponding feature flag and compile out the implementation for the fallback functions. [1] https://unix.org/whitepapers/reentrant.html Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 March 2022, 11:52:12 UTC
898225b GIT-VERSION-GEN: bump to v2.33.1 This was missed in af6d1d602a8f (Git 2.33.1, 2021-10-12). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 17 March 2022, 09:35:52 UTC
e9d7761 Git 2.34.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 November 2021, 18:55:13 UTC
d62a765 Merge branch 'jc/save-restore-terminal-revert' into maint Regression fix for 2.34 * jc/save-restore-terminal-revert: Revert "editor: save and reset terminal after calling EDITOR" 23 November 2021, 22:48:15 UTC
eef0a8e Merge branch 'ds/add-rm-with-sparse-index' into maint Regression fix for 2.34 * ds/add-rm-with-sparse-index: dir: revert "dir: select directories correctly" 23 November 2021, 22:48:11 UTC
bcef4ba Merge branch 'ab/update-submitting-patches' into maint Doc fix. * ab/update-submitting-patches: SubmittingPatches: fix Asciidoc syntax in "GitHub CI" section 23 November 2021, 22:48:08 UTC
ad03180 Merge branch 'ev/pull-already-up-to-date-is-noop' into maint "git pull" with any strategy when the other side is behind us should succeed as it is a no-op, but doesn't. * ev/pull-already-up-to-date-is-noop: pull: should be noop when already-up-to-date 23 November 2021, 22:48:04 UTC
a650ff5 Merge branch 'hm/paint-hits-in-log-grep' into maint "git grep" looking in a blob that has non-UTF8 payload was completely broken when linked with versions of PCREv2 library older than 10.34 in the latest release. * hm/paint-hits-in-log-grep: Revert "grep/pcre2: fix an edge case concerning ascii patterns and UTF-8 data" 23 November 2021, 22:48:00 UTC
e3f7e01 Revert "editor: save and reset terminal after calling EDITOR" This reverts commit 3d411afabc9a96f41d47c07d6af6edda3d29ec92, blindly opening /dev/tty and calling tcsetattr() seems to be causing problems. cf. https://bugs.eclipse.org/bugs/show_bug.cgi?id=577358 cf. https://lore.kernel.org/git/04ab7301-ea34-476c-eae4-4044fef74b91@gmail.com/ Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 November 2021, 23:04:20 UTC
33c5d6c dir: revert "dir: select directories correctly" This reverts commit f6526728f950cacfd5b5e42bcc65f2c47f3da654. The change in f652672 (dir: select directories correctly, 2021-09-24) caused a regression in directory-based matches with non-cone-mode patterns, especially for .gitignore patterns. A test is included to prevent this regression in the future. The commit ed495847 (dir: fix pattern matching on dirs, 2021-09-24) was reverted in 5ceb663 (dir: fix directory-matching bug, 2021-11-02) for similar reasons. Neither commit changed tests, and tests added later in the series continue to pass when these commits are reverted. Reported-by: Danial Alihosseini <danial.alihosseini@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 November 2021, 22:53:23 UTC
e7f3925 Revert "grep/pcre2: fix an edge case concerning ascii patterns and UTF-8 data" This reverts commit ae39ba431ab861548eb60b4bd2e1d8b8813db76f, as it breaks "grep" when looking for a string in non UTF-8 haystack, when linked with certain versions of PCREv2 library. Signed-off-by: Junio C Hamano <gitster@pobox.com> 19 November 2021, 17:10:27 UTC
ea1954a pull: should be noop when already-up-to-date The already-up-to-date pull bug was fixed for --ff-only but it did not include the case where --ff or --ff-only are not specified. This updates the --ff-only fix to include the case where --ff or --ff-only are not specified in command line flags or config. Signed-off-by: Erwin Villejo <erwin.villejo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 November 2021, 22:38:53 UTC
cd3e606 Git 2.34 Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 November 2021, 06:50:52 UTC
a288957 Merge tag 'l10n-2.34.0-rnd3.1' of git://github.com/git-l10n/git-po l10n-2.34.0-rnd3.1 * tag 'l10n-2.34.0-rnd3.1' of git://github.com/git-l10n/git-po: (38 commits) l10n: pl: 2.34.0 round 3 l10n: it: fix typos found by git-po-helper l10n: ko: fix typos found by git-po-helper l10n: Update Catalan translation l10n: po-id for 2.34 (round 3) l10n: bg.po: Updated Bulgarian translation (5211t) l10n: de.po: Update German translation for Git v2.34.0 l10n: sv.po: Update Swedish translation (5211t0f0) l10n: vi(5211t): Translation for v2.34.0 rd3 l10n: zh_TW.po: v2.34.0 round 3 (0 untranslated) l10n: fr: v2.34.0 rnd 3 l10n: tr: v2.34.0 round 3 l10n: zh_CN: v2.34.0 round 3 l10n: git.pot: v2.34.0 round 3 (1 new) l10n: pl: 2.34.0 round 2 l10n: vi(5210t): Translation for v2.34.0 rd2 l10n: es: 2.34.0 round 2 l10n: Update Catalan translation l10n: bg.po: Updated Bulgarian translation (5210t) l10n: fr: v2.34.0 round 2 ... 15 November 2021, 05:45:40 UTC
cae3877 l10n: pl: 2.34.0 round 3 Signed-off-by: Arusekk <arek_koz@o2.pl> 14 November 2021, 14:19:23 UTC
5a0724a l10n: it: fix typos found by git-po-helper Signed-off-by: Jiang Xin <worldhello.net@gmail.com> 14 November 2021, 11:40:41 UTC
edbd9f3 SubmittingPatches: fix Asciidoc syntax in "GitHub CI" section A superfluous ']' was added to the title of the GitHub CI section in f003a91f5c (SubmittingPatches: replace discussion of Travis with GitHub Actions, 2021-07-22). Remove it. While at it, format the URL for a GitHub user's workflow runs of Git between backticks, since if not Asciidoc formats only the first part, "https://github.com/<Your", as a link, which is not very useful. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 November 2021, 07:41:54 UTC
4e13fcc l10n: ko: fix typos found by git-po-helper When checking typos in file "po/ko.po", "git-po-helper" reports lots of false positives because there are no spaces between ASCII and Korean characters. After applied commit adee197 "(dict: add smudge table for Korean language, 2021-11-11)" of "git-l10n/git-po-helper" to suppress these false positives, some easy-to-fix typos are found and fixed. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> 14 November 2021, 02:01:38 UTC
1293313 l10n: Update Catalan translation Signed-off-by: Jordi Mas <jmas@softcatala.org> 13 November 2021, 15:35:53 UTC
1371836 Merge branch 'po-id' of github.com:bagasme/git-po * 'po-id' of github.com:bagasme/git-po: l10n: po-id for 2.34 (round 3) 13 November 2021, 06:42:30 UTC
d1dad7d l10n: po-id for 2.34 (round 3) - Translate following new components: * merge.c * rebase-interactive.c * rebase.c * midx.c - Clean up obsolete translations Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> 13 November 2021, 05:28:29 UTC
95d85f4 Merge branch 'master' of github.com:ruester/git-po-de * 'master' of github.com:ruester/git-po-de: l10n: de.po: Update German translation for Git v2.34.0 13 November 2021, 01:27:58 UTC
5a73c6b Merge branch 'js/trace2-raise-format-version' When we added a new event type to trace2 event stream, we forgot to raise the format version number, which has been corrected. * js/trace2-raise-format-version: trace2: increment event format version 12 November 2021, 23:29:25 UTC
2c0fa66 Merge branch 'ab/fsck-unexpected-type' Regression fix. * ab/fsck-unexpected-type: object-file: free(*contents) only in read_loose_object() caller object-file: fix SEGV on free() regression in v2.34.0-rc2 12 November 2021, 23:29:25 UTC
8996d68 Merge branch 'ps/connectivity-optim' Regression fix. * ps/connectivity-optim: Revert "connected: do not sort input revisions" 12 November 2021, 23:29:24 UTC
5f93836 l10n: bg.po: Updated Bulgarian translation (5211t) Signed-off-by: Alexander Shopov <ash@kambanaria.org> 12 November 2021, 18:24:16 UTC
db92cdb l10n: de.po: Update German translation for Git v2.34.0 Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com> Reviewed-by: Ralf Thielow <ralf.thielow@gmail.com> Reviewed-by: Phillip Szelat <phillip.szelat@gmail.com> 12 November 2021, 16:01:25 UTC
04480e6 trace2: increment event format version In 64bc752 (trace2: add trace2_child_ready() to report on background children, 2021-09-20), we added a new "child_ready" event. In Documentation/technical/api-trace2.txt, we promise that adding a new event type will result in incrementing the trace2 event format version number, but this was not done. Correct this in code & docs. Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 November 2021, 23:01:04 UTC
f29b823 l10n: sv.po: Update Swedish translation (5211t0f0) Signed-off-by: Peter Krefting <peter@softwolves.pp.se> 11 November 2021, 22:22:48 UTC
16235e3 object-file: free(*contents) only in read_loose_object() caller In the preceding commit a free() of uninitialized memory regression in 96e41f58fe1 (fsck: report invalid object type-path combinations, 2021-10-01) was fixed, but we'd still have an issue with leaking memory from fsck_loose(). Let's fix that issue too. That issue was introduced in my 31deb28f5e0 (fsck: don't hard die on invalid object types, 2021-10-01). It can be reproduced under SANITIZE=leak with the test I added in 093fffdfbec (fsck tests: add test for fsck-ing an unknown type, 2021-10-01): ./t1450-fsck.sh --run=84 -vixd In some sense it's not a problem, we lost the same amount of memory in terms of things malloc'd and not free'd. It just moved from the "still reachable" to "definitely lost" column in valgrind(1) nomenclature[1], since we'd have die()'d before. But now that we don't hard die() anymore in the library let's properly free() it. Doing so makes this code much easier to follow, since we'll now have one function owning the freeing of the "contents" variable, not two. For context on that memory management pattern the read_loose_object() function was added in f6371f92104 (sha1_file: add read_loose_object() function, 2017-01-13) and subsequently used in c68b489e564 (fsck: parse loose object paths directly, 2017-01-13). The pattern of it being the task of both sides to free() the memory has been there in this form since its inception. 1. https://valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 November 2021, 21:40:43 UTC
a7df4f5 Revert "connected: do not sort input revisions" This reverts commit f45022dc2fd692fd024f2eb41a86a66f19013d43, as this is like breakage in the traversal more likely. In a history with 10 single strand of pearls, 1-->2-->3--...->7-->8-->9-->10 asking "rev-list --unsorted-input 1 10 --not 9 8 7 6 5 4" fails to paint the bottom 1 uninteresting as the traversal stops, without completing the propagation of uninteresting bit starting at 4 down through 3 and 2 to 1. 11 November 2021, 20:34:41 UTC
168a937 object-file: fix SEGV on free() regression in v2.34.0-rc2 Fix a regression introduced in my 96e41f58fe1 (fsck: report invalid object type-path combinations, 2021-10-01). When fsck-ing blobs larger than core.bigFileThreshold, we'd free() a pointer to uninitialized memory. This issue would have been caught by SANITIZE=address, but since it involves core.bigFileThreshold, none of the existing tests in our test suite covered it. Running them with the "big_file_threshold" in "environment.c" changed to say "6" would have shown this failure, but let's add a dedicated test for this scenario based on Han Xin's report[1]. The bug was introduced between v9 and v10[2] of the fsck series merged in 061a21d36d8 (Merge branch 'ab/fsck-unexpected-type', 2021-10-25). 1. https://lore.kernel.org/git/20211111030302.75694-1-hanxin.hx@alibaba-inc.com/ 2. https://lore.kernel.org/git/cover-v10-00.17-00000000000-20211001T091051Z-avarab@gmail.com/ Reported-by: Han Xin <chiyutianyi@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 November 2021, 18:41:54 UTC
143b963 l10n: vi(5211t): Translation for v2.34.0 rd3 Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com> 11 November 2021, 06:19:34 UTC
2b98abc Merge branch 'l10n/zh_TW/211111' of github.com:l10n-tw/git-po * 'l10n/zh_TW/211111' of github.com:l10n-tw/git-po: l10n: zh_TW.po: v2.34.0 round 3 (0 untranslated) 11 November 2021, 00:28:26 UTC
f35f250 Merge branch 'fr_v2.34.0_rnd3' of github.com:jnavila/git * 'fr_v2.34.0_rnd3' of github.com:jnavila/git: l10n: fr: v2.34.0 rnd 3 11 November 2021, 00:27:49 UTC
1ffc358 Merge branch 'tr-2-34-r3' of github.com:bitigchi/git-po * 'tr-2-34-r3' of github.com:bitigchi/git-po: l10n: tr: v2.34.0 round 3 11 November 2021, 00:26:54 UTC
4d53e91 A few hotfixes Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 November 2021, 23:01:21 UTC
fe319d5 Merge branch 'jk/ssh-signing-fix' Reject OpenSSH 8.7 whose "ssh-keygen -Y find-principals" is unusable from running the ssh signature tests. * jk/ssh-signing-fix: t/lib-gpg: avoid broken versions of ssh-keygen 10 November 2021, 23:01:21 UTC
aace36f Merge branch 'js/simple-ipc-cygwin-socket-fix' The way Cygwin emulates a unix-domain socket, on top of which the simple-ipc mechanism is implemented, can race with the program on the other side that wants to use the socket, and briefly make it appear as a regular file before lstat(2) starts reporting it as a socket. We now have a workaround on the side that connects to a unix domain socket. * js/simple-ipc-cygwin-socket-fix: simple-ipc: work around issues with Cygwin's Unix socket emulation 10 November 2021, 23:01:20 UTC
c1d16ce Merge branch 'ds/no-usable-cron-on-macos' "git maintenance run" learned to use system supplied scheduler backend, but cron on macOS turns out to be unusable for this purpose. * ds/no-usable-cron-on-macos: maintenance: disable cron on macOS 10 November 2021, 23:01:20 UTC
7c7cf62 Merge branch 'jc/fix-pull-ff-only-when-already-up-to-date' "git pull --ff-only" and "git pull --rebase --ff-only" should make it a no-op to attempt pulling from a remote that is behind us, but instead the command errored out by saying it was impossible to fast-forward, which may technically be true, but not a useful thing to diagnose as an error. This has been corrected. * jc/fix-pull-ff-only-when-already-up-to-date: pull: --ff-only should make it a noop when already-up-to-date 10 November 2021, 23:01:19 UTC
569a03f l10n: zh_TW.po: v2.34.0 round 3 (0 untranslated) Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com> 10 November 2021, 22:43:41 UTC
ca7a5bf t/lib-gpg: avoid broken versions of ssh-keygen The "-Y find-principals" option of ssh-keygen seems to be broken in Debian's openssh-client 1:8.7p1-1, whereas it works fine in 1:8.4p1-5. This causes several failures for GPGSSH tests. We fulfill the prerequisite because generating the keys works fine, but actually verifying a signature causes results ranging from bogus results to ssh-keygen segfaulting. We can find the broken version during the prereq check by feeding it empty input. This should result in it complaining to stderr, but in the broken version it triggers the segfault, causing the GPGSSH tests to be skipped. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 November 2021, 22:14:37 UTC
bbb7d71 l10n: fr: v2.34.0 rnd 3 Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> 10 November 2021, 21:01:57 UTC
689a2aa maintenance: disable cron on macOS In eba1ba9 (maintenance: `git maintenance run` learned `--scheduler=<scheduler>`, 2021-09-04), we introduced the ability to specify a scheduler explicitly. This led to some extra checks around whether an alternative scheduler was available. This added the functionality of removing background maintenance from schedulers other than the one selected. On macOS, cron is technically available, but running 'crontab' triggers a UI prompt asking for special permissions. This is the major reason why launchctl is used as the default scheduler. The is_crontab_available() method triggers this UI prompt, causing user disruption. Remove this disruption by using an #ifdef to prevent running crontab this way on macOS. This has the unfortunate downside that if a user manually selects cron via the '--scheduler' option, then adjusting the scheduler later will not remove the schedule from cron. The '--scheduler' option ignores the is_available checks, which is how we can get into this situation. Extract the new check_crontab_process() method to avoid making the 'child' variable unused on macOS. The method is marked MAYBE_UNUSED because it has no callers on macOS. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 November 2021, 19:20:20 UTC
e9f197e l10n: tr: v2.34.0 round 3 Signed-off-by: Emir Sarı <bitigchi@me.com> 10 November 2021, 18:21:28 UTC
974ef7c simple-ipc: work around issues with Cygwin's Unix socket emulation Cygwin emulates Unix sockets by writing files with custom contents and then marking them as system files. The tricky problem is that while the file is written and its `system` bit is set, it is still identified as a file. This caused test failures when Git is too fast looking for the Unix sockets and then complains that there is a plain file in the way. Let's work around this by adding a delayed retry loop, specifically for Cygwin. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Tested-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 November 2021, 17:12:19 UTC
ffa1451 l10n: zh_CN: v2.34.0 round 3 Signed-off-by: Fangyi Zhou <me@fangyi.io> 10 November 2021, 12:33:51 UTC
bc9adb4 Merge branch 'master' of github.com:alshopov/git-po * 'master' of github.com:alshopov/git-po: l10n: bg.po: Updated Bulgarian translation (5210t) 10 November 2021, 02:18:44 UTC
d834438 l10n: git.pot: v2.34.0 round 3 (1 new) Generate po/git.pot from v2.34.0-rc2 for git v2.34.0 l10n round 3. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> 10 November 2021, 00:56:22 UTC
3a61600 Merge branch 'master' of github.com:git/git * 'master' of github.com:git/git: Git 2.34-rc2 parse-options.[ch]: revert use of "enum" for parse_options() t/lib-git.sh: fix ACL-related permissions failure A few fixes before -rc2 async_die_is_recursing: work around GCC v11.x issue on Fedora Document positive variant of commit and merge option "--no-verify" pull: honor --no-verify and do not call the commit-msg hook http-backend: remove a duplicated code branch 10 November 2021, 00:55:14 UTC
6c22093 Git 2.34-rc2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 November 2021, 21:19:51 UTC
84c99b2 Merge branch 'ab/parse-options-cleanup' Last minute fix to the update already in 'master'. * ab/parse-options-cleanup: parse-options.[ch]: revert use of "enum" for parse_options() 09 November 2021, 21:19:06 UTC
92dd0a5 Merge branch 'ad/ssh-signing-testfix' Fix ssh-signing test to work on a platform where the default ACL is overly loose to upset OpenSSH (reported on an installation of Cygwin). * ad/ssh-signing-testfix: t/lib-git.sh: fix ACL-related permissions failure 09 November 2021, 21:19:06 UTC
06a199f parse-options.[ch]: revert use of "enum" for parse_options() Revert the parse_options() prototype change in my recent 352e761388b (parse-options.[ch]: consistently use "enum parse_opt_result", 2021-10-08) was incorrect. The parse_options() function returns the number of argc elements that haven't been processed, not "enum parse_opt_result". Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 November 2021, 17:45:37 UTC
ed7fe7b l10n: pl: 2.34.0 round 2 Signed-off-by: Arusekk <arek_koz@o2.pl> 09 November 2021, 13:59:51 UTC
d3600a1 l10n: vi(5210t): Translation for v2.34.0 rd2 Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com> 08 November 2021, 02:02:58 UTC
09fb894 l10n: es: 2.34.0 round 2 Signed-off-by: Christopher Diaz Riveros <christopher.diaz.riv@gmail.com> Signed-off-by: Omar Olivares <omar@olivares.cl> Signed-off-by: Jaime Marquínez Ferrándiz <jaime.marquinez.ferrandiz@fastmail.net> Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> 08 November 2021, 00:13:01 UTC
fa800af l10n: Update Catalan translation Signed-off-by: Jordi Mas <jmas@softcatala.org> 06 November 2021, 12:43:08 UTC
ed5fa68 l10n: bg.po: Updated Bulgarian translation (5210t) Signed-off-by: Alexander Shopov <ash@kambanaria.org> 06 November 2021, 11:17:35 UTC
1b372d1 Merge branch 'pt-PT' of github.com:git-l10n-pt-PT/git-po * 'pt-PT' of github.com:git-l10n-pt-PT/git-po: l10n: pt_PT: cleaning duplicate translations (#2) 06 November 2021, 04:32:08 UTC
26274f2 Merge branch 'l10n/zh_TW/211104' of github.com:l10n-tw/git-po * 'l10n/zh_TW/211104' of github.com:l10n-tw/git-po: l10n: zh_TW.po: v2.34.0 round 2 (0 untranslated) 06 November 2021, 04:16:02 UTC
7140c49 t/lib-git.sh: fix ACL-related permissions failure As well as checking that the relevant functionality is available, the GPGSSH prerequisite check creates the SSH keys that are used by the test functions it gates. If these keys are created in a directory that has a default Access Control List, the key files can inherit those permissions. This can result in a scenario where the private keys are created successfully, so the prerequisite check passes and the tests are run, but the key files have permissions that are too permissive, meaning OpenSSH will refuse to load them and the tests will fail. To avoid this happening, before creating the keys, clear any default ACL set on the directory that will contain them. This step allowed to fail; if setfacl isn't present, that's a very likely indicator that the filesystem in question simply doesn't support default ACLs. Helped-by: Fabian Stelzer <fs@gigacodes.de> Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 November 2021, 20:44:37 UTC
3a7746a l10n: fr: v2.34.0 round 2 Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> 05 November 2021, 19:41:17 UTC
back to top