summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)Author
2023-02-06Git 2.34.7v2.34.7Johannes Schindelin
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2023-02-06Sync with 2.33.7Johannes Schindelin
* maint-2.33: Git 2.33.7 Git 2.32.6 Git 2.31.7 Git 2.30.8 apply: fix writing behind newly created symbolic links dir-iterator: prevent top-level symlinks without FOLLOW_SYMLINKS clone: delay picking a transport until after get_repo_path() t5619: demonstrate clone_local() with ambiguous transport
2023-02-06Git 2.33.7v2.33.7Johannes Schindelin
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2023-02-06Sync with 2.32.6Johannes Schindelin
* maint-2.32: Git 2.32.6 Git 2.31.7 Git 2.30.8 apply: fix writing behind newly created symbolic links dir-iterator: prevent top-level symlinks without FOLLOW_SYMLINKS clone: delay picking a transport until after get_repo_path() t5619: demonstrate clone_local() with ambiguous transport
2023-02-06Git 2.32.6v2.32.6Johannes Schindelin
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2023-02-06Sync with 2.31.7Johannes Schindelin
* maint-2.31: Git 2.31.7 Git 2.30.8 apply: fix writing behind newly created symbolic links dir-iterator: prevent top-level symlinks without FOLLOW_SYMLINKS clone: delay picking a transport until after get_repo_path() t5619: demonstrate clone_local() with ambiguous transport
2023-02-06Git 2.31.7v2.31.7Johannes Schindelin
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2023-02-06Sync with 2.30.8Johannes Schindelin
* maint-2.30: Git 2.30.8 apply: fix writing behind newly created symbolic links dir-iterator: prevent top-level symlinks without FOLLOW_SYMLINKS clone: delay picking a transport until after get_repo_path() t5619: demonstrate clone_local() with ambiguous transport
2023-02-06Git 2.30.8v2.30.8Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-12-13Git 2.34.6v2.34.6Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-12-13Merge branch 'maint-2.33' into maint-2.34Junio C Hamano
2022-12-13Git 2.33.6v2.33.6Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-12-13Sync with Git 2.32.5Junio C Hamano
2022-12-13Git 2.32.5v2.32.5Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-12-13Sync with Git 2.31.6Junio C Hamano
2022-12-13Git 2.31.6v2.31.6Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-12-13Sync with Git 2.30.7Junio C Hamano
2022-12-13Git 2.30.7v2.30.7Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-10-06Git 2.34.5v2.34.5Taylor Blau
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-06Sync with 2.33.5Taylor Blau
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-06Git 2.33.5v2.33.5Taylor Blau
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-06Sync with 2.32.4Taylor Blau
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-06Git 2.32.4v2.32.4Taylor Blau
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-06Sync with 2.31.5Taylor Blau
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-06Git 2.31.5v2.31.5Taylor Blau
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-06Sync with 2.30.6Taylor Blau
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-06Git 2.30.6v2.30.6Taylor Blau
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-10-01transport: make `protocol.file.allow` be "user" by defaultTaylor Blau
An earlier patch discussed and fixed a scenario where Git could be used as a vector to exfiltrate sensitive data through a Docker container when a potential victim clones a suspicious repository with local submodules that contain symlinks. That security hole has since been plugged, but a similar one still exists. Instead of convincing a would-be victim to clone an embedded submodule via the "file" protocol, an attacker could convince an individual to clone a repository that has a submodule pointing to a valid path on the victim's filesystem. For example, if an individual (with username "foo") has their home directory ("/home/foo") stored as a Git repository, then an attacker could exfiltrate data by convincing a victim to clone a malicious repository containing a submodule pointing at "/home/foo/.git" with `--recurse-submodules`. Doing so would expose any sensitive contents in stored in "/home/foo" tracked in Git. For systems (such as Docker) that consider everything outside of the immediate top-level working directory containing a Dockerfile as inaccessible to the container (with the exception of volume mounts, and so on), this is a violation of trust by exposing unexpected contents in the working copy. To mitigate the likelihood of this kind of attack, adjust the "file://" protocol's default policy to be "user" to prevent commands that execute without user input (including recursive submodule initialization) from taking place by default. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-06-23Git 2.34.4v2.34.4Johannes Schindelin
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-06-23Sync with 2.33.4Johannes Schindelin
* 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
2022-06-23Git 2.33.4v2.33.4Johannes Schindelin
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-06-23Sync with 2.32.3Johannes Schindelin
* 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
2022-06-23Git 2.32.3v2.32.3Johannes Schindelin
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-06-23Sync with 2.31.4Johannes Schindelin
* 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
2022-06-23Git 2.31.4v2.31.4Johannes Schindelin
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-06-23Sync with 2.30.5Johannes Schindelin
* 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
2022-06-23Git 2.30.5v2.30.5Johannes Schindelin
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-06-17git-compat-util: allow root to access both SUDO_UID and root ownedCarlo Marcelo Arenas Belón
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>
2022-05-12git-compat-util: avoid failing dir ownership checks if running privilegedCarlo Marcelo Arenas Belón
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>
2022-04-13Git 2.34.3v2.34.3Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-13Git 2.33.3v2.33.3Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-13Git 2.32.2v2.32.2Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-13Git 2.31.3v2.31.3Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-13Git 2.30.4v2.30.4Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-13setup: opt-out of check with safe.directory=*Derrick Stolee
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>
2022-03-24Git 2.34.2v2.34.2Johannes Schindelin
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-03-24Sync with 2.33.2Johannes Schindelin
* 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
2022-03-24Git 2.33.2v2.33.2Johannes Schindelin
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2022-03-24Sync with 2.32.1Johannes Schindelin
* 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
2022-03-24Git 2.32.1v2.32.1Johannes Schindelin
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 08:39:55 +0000