kernel/git - git - PowerEL Git System

Author	SHA1	Message	Date
Taylor Blau	a1d4f67c12	transport: make `protocol.file.allow` be "user" by default 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>	2 years ago
Jeff King	eb049759fb	protocol: re-enable v2 protocol by default Protocol v2 became the default in v2.26.0 via `684ceae32d` (fetch: default to protocol version 2, 2019-12-23). More widespread use turned up a regression in negotiation. That was fixed in v2.27.0 via `4fa3f00abb` (fetch-pack: in protocol v2, in_vain only after ACK, 2020-04-27), but we also reverted the default to v0 as a precuation in `11c7f2a30b` (Revert "fetch: default to protocol version 2", 2020-04-22). In v2.28.0, we re-enabled it for experimental users with `3697caf4b9` (config: let feature.experimental imply protocol.version=2, 2020-05-20) and haven't heard any complaints. v2.28 has only been out for 2 months, but I'd generally expect people turning on feature.experimental to also stay pretty up-to-date. So we're not likely to collect much more data by waiting. In addition, we have no further reports from people running v2.26.0, and of course some people have been setting protocol.version manually for ages. Let's move forward with v2 as the default again. It's possible there are still lurking bugs, but we won't know until it gets more widespread use. And we can find and squash them just like any other bug at this point. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Jonathan Nieder	3697caf4b9	config: let feature.experimental imply protocol.version=2 Git 2.26 used protocol v2 as its default protocol, but soon after release, users noticed that the protocol v2 negotiation code was prone to fail when fetching from some remotes that are far ahead of others (such as linux-next.git versus Linus's linux.git). That has been fixed by `0b07eecf6e` (Merge branch 'jt/v2-fetch-nego-fix', 2020-05-01), but to be cautious, we are using protocol v0 as the default in 2.27 to buy some time for any other unanticipated issues to surface. To that end, let's ensure that users requesting the bleeding edge using the feature.experimental flag do get protocol v2. This way, we can gain experience with a wider audience for the new protocol version and be more confident when it is time to enable it by default for all users in some future Git version. Implementation note: this isn't with the rest of the feature.experimental options in repo-settings.c because those are tied to a repository object, whereas this code path is used for operations like "git ls-remote" that do not require a repository. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jonathan Nieder	11c7f2a30b	Revert "fetch: default to protocol version 2" This reverts commit `684ceae32d`. Users fetching from linux-next and other kernel remotes are reporting that the limited ref advertisement causes negotiation to reach MAX_IN_VAIN, resulting in too-large fetches. Reported-by: Lubomir Rintel <lkundrak@v3.sk> Reported-by: "Dixit, Ashutosh" <ashutosh.dixit@intel.com> Reported-by: Jiri Slaby <jslaby@suse.cz> Reported-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jonathan Nieder	684ceae32d	fetch: default to protocol version 2 The Git users at $DAYJOB have been using protocol v2 as a default for ~1.5 years now and others have been also reporting good experiences with it, so it seems like a good time to bump the default version. It produces a significant performance improvement when fetching from repositories with many refs, such as https://chromium.googlesource.com/chromium/src. This only affects the client, not the server. (The server already defaults to supporting protocol v2.) The protocol change is backward compatible, so this should produce no significant effect when contacting servers that only speak protocol v0. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jonathan Nieder	b9ab170752	config doc: protocol.version is not experimental Git's protocol version 2 has been working well in production for over a year. Simplify documentation by no longer referring to it as experimental. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Nguyễn Thái Ngọc Duy	dd55172c32	config.txt: move protocol.* to a separate file Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago