summaryrefslogtreecommitdiff
path: root/Documentation/RelNotes/2.6.4.txt
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2017-07-28 15:26:50 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-07-28 15:52:18 -0700
commit3be4cf09cd3d0747af3ecdb8dc3962a0969b731e (patch)
tree1bc7773276b260a31f29bb335c6ce97f5632f6f4 /Documentation/RelNotes/2.6.4.txt
parentconnect: factor out "looks like command line option" check (diff)
downloadtgif-3be4cf09cd3d0747af3ecdb8dc3962a0969b731e.tar.xz
connect: reject dashed arguments for proxy commands
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 <port>", 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 <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/RelNotes/2.6.4.txt')
0 files changed, 0 insertions, 0 deletions