git, branch v2.23.3

Git 2.23.3

2020-04-19T23:30:27Z

This merges up the security fix from v2.17.5. Signed-off-by: Jonathan Nieder

Git 2.22.4

2020-04-19T23:30:19Z

This merges up the security fix from v2.17.5. Signed-off-by: Jonathan Nieder

Git 2.21.3

2020-04-19T23:30:08Z

This merges up the security fix from v2.17.5. Signed-off-by: Jonathan Nieder

Git 2.20.4

2020-04-19T23:28:57Z

This merges up the security fix from v2.17.5. Signed-off-by: Jonathan Nieder

Git 2.19.5

2020-04-19T23:26:41Z

This merges up the security fix from v2.17.5. Signed-off-by: Jonathan Nieder

Git 2.18.4

2020-04-19T23:24:14Z

This merges up the security fix from v2.17.5. Signed-off-by: Jonathan Nieder

Git 2.17.5

2020-04-19T23:10:58Z

Signed-off-by: Jeff King Signed-off-by: Jonathan Nieder

fsck: reject URL with empty host in .gitmodules

2020-04-19T23:10:58Z

Git's URL parser interprets https:///example.com/repo.git to have no host and a path of "example.com/repo.git". Curl, on the other hand, internally redirects it to https://example.com/repo.git. As a result, until "credential: parse URL without host as empty host, not unset", tricking a user into fetching from such a URL would cause Git to send credentials for another host to example.com. Teach fsck to block and detect .gitmodules files using such a URL to prevent sharing them with Git versions that are not yet protected. A relative URL in a .gitmodules file could also be used to trigger this. The relative URL resolver used for .gitmodules does not normalize sequences of slashes and can follow ".." components out of the path part and to the host part of a URL, meaning that such a relative URL can be used to traverse from a https://foo.example.com/innocent superproject to a https:///attacker.example.com/exploit submodule. Fortunately, redundant extra slashes in .gitmodules are rare, so we can catch this by detecting one after a leading sequence of "./" and "../" components. Helped-by: Jeff King Signed-off-by: Jonathan Nieder Reviewed-by: Jeff King

credential: treat URL with empty scheme as invalid

2020-04-19T23:10:58Z

Until "credential: refuse to operate when missing host or protocol", Git's credential handling code interpreted URLs with empty scheme to mean "give me credentials matching this host for any protocol". Luckily libcurl does not recognize such URLs (it tries to look for a protocol named "" and fails). Just in case that changes, let's reject them within Git as well. This way, credential_from_url is guaranteed to always produce a "struct credential" with protocol and host set. Signed-off-by: Jonathan Nieder

credential: treat URL without scheme as invalid

2020-04-19T23:10:58Z

libcurl permits making requests without a URL scheme specified. In this case, it guesses the URL from the hostname, so I can run git ls-remote http::ftp.example.com/path/to/repo and it would make an FTP request. Any user intentionally using such a URL is likely to have made a typo. Unfortunately, credential_from_url is not able to determine the host and protocol in order to determine appropriate credentials to send, and until "credential: refuse to operate when missing host or protocol", this resulted in another host's credentials being leaked to the named host. Teach credential_from_url_gently to consider such a URL to be invalid so that fsck can detect and block gitmodules files with such URLs, allowing server operators to avoid serving them to downstream users running older versions of Git. This also means that when such URLs are passed on the command line, Git will print a clearer error so affected users can switch to the simpler URL that explicitly specifies the host and protocol they intend. One subtlety: .gitmodules files can contain relative URLs, representing a URL relative to the URL they were cloned from. The relative URL resolver used for .gitmodules can follow ".." components out of the path part and past the host part of a URL, meaning that such a relative URL can be used to traverse from a https://foo.example.com/innocent superproject to a https::attacker.example.com/exploit submodule. Fortunately a leading ':' in the first path component after a series of leading './' and '../' components is unlikely to show up in other contexts, so we can catch this by detecting that pattern. Reported-by: Jeff King Signed-off-by: Jonathan Nieder Reviewed-by: Jeff King