summaryrefslogtreecommitdiff
path: root/t/t5813-proto-disable-ssh.sh
AgeCommit message (Collapse)AuthorFilesLines
2017-07-28connect: reject paths that look like command line optionsLibravatar Jeff King1-0/+14
If we get a repo path like "-repo.git", we may try to invoke "git-upload-pack -repo.git". This is going to fail, since upload-pack will interpret it as a set of bogus options. But let's reject this before we even run the sub-program, since we would not want to allow any mischief with repo names that actually are real command-line options. You can still ask for such a path via git-daemon, but there's no security problem there, because git-daemon enters the repo itself and then passes "." on the command line. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-28t5813: add test for hostname starting with dashLibravatar Jeff King1-0/+9
Per the explanation in the previous patch, this should be (and is) rejected. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-20t5813: avoid creating urls that break on cygwinLibravatar Dennis Kaarsemaker1-2/+2
When passed an ssh:// url, git strips ssh://host from the url but does not remove leading slashes from the path. So when this test used ssh://remote//path/to/pwd, the path accessed by our fake SSH is //path/to/pwd, which cygwin interprets as a UNC path, causing the test to fail. We may want to actually fix this in git itself, making it remove extra slashes from urls before feeding them to transports or helpers, but that's for another topic as it could cause regressions. Signed-off-by: Dennis Kaarsemaker <dennis@kaarsemaker.net> Signed-off-by: Jeff King <peff@peff.net>
2015-09-23transport: add a protocol-whitelist environment variableLibravatar Jeff King1-0/+20
If we are cloning an untrusted remote repository into a sandbox, we may also want to fetch remote submodules in order to get the complete view as intended by the other side. However, that opens us up to attacks where a malicious user gets us to clone something they would not otherwise have access to (this is not necessarily a problem by itself, but we may then act on the cloned contents in a way that exposes them to the attacker). Ideally such a setup would sandbox git entirely away from high-value items, but this is not always practical or easy to set up (e.g., OS network controls may block multiple protocols, and we would want to enable some but not others). We can help this case by providing a way to restrict particular protocols. We use a whitelist in the environment. This is more annoying to set up than a blacklist, but defaults to safety if the set of protocols git supports grows). If no whitelist is specified, we continue to default to allowing all protocols (this is an "unsafe" default, but since the minority of users will want this sandboxing effect, it is the only sensible one). A note on the tests: ideally these would all be in a single test file, but the git-daemon and httpd test infrastructure is an all-or-nothing proposition rather than a test-by-test prerequisite. By putting them all together, we would be unable to test the file-local code on machines without apache. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>