git, branch v2.9.5

Git 2.9.5

2017-07-30T21:53:25Z

Signed-off-by: Junio C Hamano

Merge tag 'v2.8.6' into maint-2.9

2017-07-30T21:52:14Z

Git 2.8.6

2017-07-30T21:49:08Z

Signed-off-by: Junio C Hamano

Merge tag 'v2.7.6' into maint-2.8

2017-07-30T21:46:43Z

Git 2.7.6

2017-07-30T21:45:13Z

Signed-off-by: Junio C Hamano

Merge branch 'jk/ssh-funny-url' into maint-2.7

2017-07-28T23:11:54Z

connect: reject paths that look like command line options

2017-07-28T22:54:55Z

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 Reviewed-by: Jonathan Nieder Signed-off-by: Junio C Hamano

connect: reject dashed arguments for proxy commands

2017-07-28T22:52:18Z

If you have a GIT_PROXY_COMMAND configured, we will run it with the host/port on the command-line. If a URL contains a mischievous host like "--foo", we don't know how the proxy command may handle it. It's likely to break, but it may also do something dangerous and unwanted (technically it could even do something useful, but that seems unlikely). We should err on the side of caution and reject this before we even run the command. The hostname check matches the one we do in a similar circumstance for ssh. The port check is not present for ssh, but there it's not necessary because the syntax is "-p ", and there's no ambiguity on the parsing side. It's not clear whether you can actually get a negative port to the proxy here or not. Doing: git fetch git://remote:-1234/repo.git keeps the "-1234" as part of the hostname, with the default port of 9418. But it's a good idea to keep this check close to the point of running the command to make it clear that there's no way to circumvent it (and at worst it serves as a belt-and-suspenders check). Signed-off-by: Jeff King Reviewed-by: Jonathan Nieder Signed-off-by: Junio C Hamano

connect: factor out "looks like command line option" check

2017-07-28T22:51:56Z

We reject hostnames that start with a dash because they may be confused for command-line options. Let's factor out that notion into a helper function, as we'll use it in more places. And while it's simple now, it's not clear if some systems might need more complex logic to handle all cases. Signed-off-by: Jeff King Reviewed-by: Jonathan Nieder Signed-off-by: Junio C Hamano

t5813: add test for hostname starting with dash

2017-07-28T22:51:29Z

Per the explanation in the previous patch, this should be (and is) rejected. Signed-off-by: Jeff King Reviewed-by: Jonathan Nieder Signed-off-by: Junio C Hamano