2012-01-07 11:42:45 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description='test fetching over git protocol'
|
2020-11-18 23:44:34 +00:00
|
|
|
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
|
tests: mark tests relying on the current default for `init.defaultBranch`
In addition to the manual adjustment to let the `linux-gcc` CI job run
the test suite with `master` and then with `main`, this patch makes sure
that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts
that currently rely on the initial branch name being `master by default.
To determine which test scripts to mark up, the first step was to
force-set the default branch name to `master` in
- all test scripts that contain the keyword `master`,
- t4211, which expects `t/t4211/history.export` with a hard-coded ref to
initialize the default branch,
- t5560 because it sources `t/t556x_common` which uses `master`,
- t8002 and t8012 because both source `t/annotate-tests.sh` which also
uses `master`)
This trick was performed by this command:
$ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\
' $(git grep -l master t/t[0-9]*.sh) \
t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh
After that, careful, manual inspection revealed that some of the test
scripts containing the needle `master` do not actually rely on a
specific default branch name: either they mention `master` only in a
comment, or they initialize that branch specificially, or they do not
actually refer to the current default branch. Therefore, the
aforementioned modification was undone in those test scripts thusly:
$ git checkout HEAD -- \
t/t0027-auto-crlf.sh t/t0060-path-utils.sh \
t/t1011-read-tree-sparse-checkout.sh \
t/t1305-config-include.sh t/t1309-early-config.sh \
t/t1402-check-ref-format.sh t/t1450-fsck.sh \
t/t2024-checkout-dwim.sh \
t/t2106-update-index-assume-unchanged.sh \
t/t3040-subprojects-basic.sh t/t3301-notes.sh \
t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \
t/t3436-rebase-more-options.sh \
t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \
t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \
t/t5511-refspec.sh t/t5526-fetch-submodules.sh \
t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \
t/t5548-push-porcelain.sh \
t/t5552-skipping-fetch-negotiator.sh \
t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \
t/t5614-clone-submodules-shallow.sh \
t/t7508-status.sh t/t7606-merge-custom.sh \
t/t9302-fast-import-unpack-limit.sh
We excluded one set of test scripts in these commands, though: the range
of `git p4` tests. The reason? `git p4` stores the (foreign) remote
branch in the branch called `p4/master`, which is obviously not the
default branch. Manual analysis revealed that only five of these tests
actually require a specific default branch name to pass; They were
modified thusly:
$ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\
' t/t980[0167]*.sh t/t9811*.sh
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-18 23:44:19 +00:00
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
|
2012-01-07 11:42:45 +00:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
|
|
. "$TEST_DIRECTORY"/lib-git-daemon.sh
|
|
|
|
|
start_git_daemon
|
|
|
|
|
|
2016-02-14 09:26:29 +00:00
|
|
|
check_verbose_connect () {
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep -F "Looking up 127.0.0.1 ..." stderr &&
|
|
|
|
|
test_grep -F "Connecting to 127.0.0.1 (port " stderr &&
|
|
|
|
|
test_grep -F "done." stderr
|
2016-02-14 09:26:29 +00:00
|
|
|
}
|
|
|
|
|
|
2012-01-07 11:42:45 +00:00
|
|
|
test_expect_success 'setup repository' '
|
2013-01-16 02:05:08 +00:00
|
|
|
git config push.default matching &&
|
2012-01-07 11:42:45 +00:00
|
|
|
echo content >file &&
|
|
|
|
|
git add file &&
|
|
|
|
|
git commit -m one
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'create git-accessible bare repository' '
|
|
|
|
|
mkdir "$GIT_DAEMON_DOCUMENT_ROOT_PATH/repo.git" &&
|
|
|
|
|
(cd "$GIT_DAEMON_DOCUMENT_ROOT_PATH/repo.git" &&
|
|
|
|
|
git --bare init &&
|
|
|
|
|
: >git-daemon-export-ok
|
|
|
|
|
) &&
|
|
|
|
|
git remote add public "$GIT_DAEMON_DOCUMENT_ROOT_PATH/repo.git" &&
|
2020-11-18 23:44:34 +00:00
|
|
|
git push public main:main
|
2012-01-07 11:42:45 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'clone git repository' '
|
2016-02-14 09:26:29 +00:00
|
|
|
git clone -v "$GIT_DAEMON_URL/repo.git" clone 2>stderr &&
|
|
|
|
|
check_verbose_connect &&
|
2012-01-07 11:42:45 +00:00
|
|
|
test_cmp file clone/file
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'fetch changes via git protocol' '
|
|
|
|
|
echo content >>file &&
|
|
|
|
|
git commit -a -m two &&
|
|
|
|
|
git push public &&
|
2016-02-14 09:26:29 +00:00
|
|
|
(cd clone && git pull -v) 2>stderr &&
|
|
|
|
|
check_verbose_connect &&
|
2012-01-07 11:42:45 +00:00
|
|
|
test_cmp file clone/file
|
|
|
|
|
'
|
|
|
|
|
|
2016-02-14 09:26:29 +00:00
|
|
|
test_expect_success 'no-op fetch -v stderr is as expected' '
|
|
|
|
|
(cd clone && git fetch -v) 2>stderr &&
|
|
|
|
|
check_verbose_connect
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'no-op fetch without "-v" is quiet' '
|
2018-02-23 23:39:47 +00:00
|
|
|
(cd clone && git fetch 2>../stderr) &&
|
2018-08-19 21:57:22 +00:00
|
|
|
test_must_be_empty stderr
|
2016-02-14 09:26:29 +00:00
|
|
|
'
|
|
|
|
|
|
2013-10-21 17:54:11 +00:00
|
|
|
test_expect_success 'remote detects correct HEAD' '
|
2020-11-18 23:44:34 +00:00
|
|
|
git push public main:other &&
|
2012-01-07 11:42:45 +00:00
|
|
|
(cd clone &&
|
|
|
|
|
git remote set-head -d origin &&
|
|
|
|
|
git remote set-head -a origin &&
|
|
|
|
|
git symbolic-ref refs/remotes/origin/HEAD > output &&
|
2020-11-18 23:44:34 +00:00
|
|
|
echo refs/remotes/origin/main > expect &&
|
2012-01-07 11:42:45 +00:00
|
|
|
test_cmp expect output
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'prepare pack objects' '
|
|
|
|
|
cp -R "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo.git "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_pack.git &&
|
|
|
|
|
(cd "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_pack.git &&
|
|
|
|
|
git --bare repack -a -d
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'fetch notices corrupt pack' '
|
|
|
|
|
cp -R "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_pack.git "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_bad1.git &&
|
|
|
|
|
(cd "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_bad1.git &&
|
2016-01-04 09:10:48 +00:00
|
|
|
p=$(ls objects/pack/pack-*.pack) &&
|
2012-01-07 11:42:45 +00:00
|
|
|
chmod u+w $p &&
|
|
|
|
|
printf %0256d 0 | dd of=$p bs=256 count=1 seek=1 conv=notrunc
|
|
|
|
|
) &&
|
|
|
|
|
mkdir repo_bad1.git &&
|
|
|
|
|
(cd repo_bad1.git &&
|
|
|
|
|
git --bare init &&
|
|
|
|
|
test_must_fail git --bare fetch "$GIT_DAEMON_URL/repo_bad1.git" &&
|
2016-01-04 09:10:48 +00:00
|
|
|
test 0 = $(ls objects/pack/pack-*.pack | wc -l)
|
2012-01-07 11:42:45 +00:00
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'fetch notices corrupt idx' '
|
|
|
|
|
cp -R "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_pack.git "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_bad2.git &&
|
|
|
|
|
(cd "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_bad2.git &&
|
2019-04-05 18:06:22 +00:00
|
|
|
rm -f objects/pack/multi-pack-index &&
|
2016-01-04 09:10:48 +00:00
|
|
|
p=$(ls objects/pack/pack-*.idx) &&
|
2012-01-07 11:42:45 +00:00
|
|
|
chmod u+w $p &&
|
|
|
|
|
printf %0256d 0 | dd of=$p bs=256 count=1 seek=1 conv=notrunc
|
|
|
|
|
) &&
|
|
|
|
|
mkdir repo_bad2.git &&
|
|
|
|
|
(cd repo_bad2.git &&
|
|
|
|
|
git --bare init &&
|
|
|
|
|
test_must_fail git --bare fetch "$GIT_DAEMON_URL/repo_bad2.git" &&
|
2016-01-04 09:10:48 +00:00
|
|
|
test 0 = $(ls objects/pack | wc -l)
|
2012-01-07 11:42:45 +00:00
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
git_connect_git(): forbid newlines in host and path
When we connect to a git:// server, we send an initial request that
looks something like:
002dgit-upload-pack repo.git\0host=example.com
If the repo path contains a newline, then it's included literally, and
we get:
002egit-upload-pack repo
.git\0host=example.com
This works fine if you really do have a newline in your repository name;
the server side uses the pktline framing to parse the string, not
newlines. However, there are many _other_ protocols in the wild that do
parse on newlines, such as HTTP. So a carefully constructed git:// URL
can actually turn into a valid HTTP request. For example:
git://localhost:1234/%0d%0a%0d%0aGET%20/%20HTTP/1.1 %0d%0aHost:localhost%0d%0a%0d%0a
becomes:
0050git-upload-pack /
GET / HTTP/1.1
Host:localhost
host=localhost:1234
on the wire. Again, this isn't a problem for a real Git server, but it
does mean that feeding a malicious URL to Git (e.g., through a
submodule) can cause it to make unexpected cross-protocol requests.
Since repository names with newlines are presumably quite rare (and
indeed, we already disallow them in git-over-http), let's just disallow
them over this protocol.
Hostnames could likewise inject a newline, but this is unlikely a
problem in practice; we'd try resolving the hostname with a newline in
it, which wouldn't work. Still, it doesn't hurt to err on the side of
caution there, since we would not expect them to work in the first
place.
The ssh and local code paths are unaffected by this patch. In both cases
we're trying to run upload-pack via a shell, and will quote the newline
so that it makes it intact. An attacker can point an ssh url at an
arbitrary port, of course, but unless there's an actual ssh server
there, we'd never get as far as sending our shell command anyway. We
_could_ similarly restrict newlines in those protocols out of caution,
but there seems little benefit to doing so.
The new test here is run alongside the git-daemon tests, which cover the
same protocol, but it shouldn't actually contact the daemon at all. In
theory we could make the test more robust by setting up an actual
repository with a newline in it (so that our clone would succeed if our
new check didn't kick in). But a repo directory with newline in it is
likely not portable across all filesystems. Likewise, we could check
git-daemon's log that it was not contacted at all, but we do not
currently record the log (and anyway, it would make the test racy with
the daemon's log write). We'll just check the client-side stderr to make
sure we hit the expected code path.
Reported-by: Harold Kim <h.kim@flatt.tech>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-07 09:43:58 +00:00
|
|
|
test_expect_success 'client refuses to ask for repo with newline' '
|
|
|
|
|
test_must_fail git clone "$GIT_DAEMON_URL/repo$LF.git" dst 2>stderr &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep newline.is.forbidden stderr
|
git_connect_git(): forbid newlines in host and path
When we connect to a git:// server, we send an initial request that
looks something like:
002dgit-upload-pack repo.git\0host=example.com
If the repo path contains a newline, then it's included literally, and
we get:
002egit-upload-pack repo
.git\0host=example.com
This works fine if you really do have a newline in your repository name;
the server side uses the pktline framing to parse the string, not
newlines. However, there are many _other_ protocols in the wild that do
parse on newlines, such as HTTP. So a carefully constructed git:// URL
can actually turn into a valid HTTP request. For example:
git://localhost:1234/%0d%0a%0d%0aGET%20/%20HTTP/1.1 %0d%0aHost:localhost%0d%0a%0d%0a
becomes:
0050git-upload-pack /
GET / HTTP/1.1
Host:localhost
host=localhost:1234
on the wire. Again, this isn't a problem for a real Git server, but it
does mean that feeding a malicious URL to Git (e.g., through a
submodule) can cause it to make unexpected cross-protocol requests.
Since repository names with newlines are presumably quite rare (and
indeed, we already disallow them in git-over-http), let's just disallow
them over this protocol.
Hostnames could likewise inject a newline, but this is unlikely a
problem in practice; we'd try resolving the hostname with a newline in
it, which wouldn't work. Still, it doesn't hurt to err on the side of
caution there, since we would not expect them to work in the first
place.
The ssh and local code paths are unaffected by this patch. In both cases
we're trying to run upload-pack via a shell, and will quote the newline
so that it makes it intact. An attacker can point an ssh url at an
arbitrary port, of course, but unless there's an actual ssh server
there, we'd never get as far as sending our shell command anyway. We
_could_ similarly restrict newlines in those protocols out of caution,
but there seems little benefit to doing so.
The new test here is run alongside the git-daemon tests, which cover the
same protocol, but it shouldn't actually contact the daemon at all. In
theory we could make the test more robust by setting up an actual
repository with a newline in it (so that our clone would succeed if our
new check didn't kick in). But a repo directory with newline in it is
likely not portable across all filesystems. Likewise, we could check
git-daemon's log that it was not contacted at all, but we do not
currently record the log (and anyway, it would make the test racy with
the daemon's log write). We'll just check the client-side stderr to make
sure we hit the expected code path.
Reported-by: Harold Kim <h.kim@flatt.tech>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-07 09:43:58 +00:00
|
|
|
'
|
|
|
|
|
|
2012-01-07 11:42:45 +00:00
|
|
|
test_remote_error()
|
|
|
|
|
{
|
|
|
|
|
do_export=YesPlease
|
|
|
|
|
while test $# -gt 0
|
|
|
|
|
do
|
|
|
|
|
case $1 in
|
|
|
|
|
-x)
|
|
|
|
|
shift
|
|
|
|
|
chmod -x "$GIT_DAEMON_DOCUMENT_ROOT_PATH/repo.git"
|
|
|
|
|
;;
|
|
|
|
|
-n)
|
|
|
|
|
shift
|
|
|
|
|
do_export=
|
|
|
|
|
;;
|
|
|
|
|
*)
|
|
|
|
|
break
|
|
|
|
|
esac
|
|
|
|
|
done
|
|
|
|
|
|
2012-04-24 07:50:04 +00:00
|
|
|
msg=$1
|
|
|
|
|
shift
|
2012-01-07 11:42:45 +00:00
|
|
|
cmd=$1
|
2012-04-24 07:50:04 +00:00
|
|
|
shift
|
|
|
|
|
repo=$1
|
|
|
|
|
shift || error "invalid number of arguments"
|
2012-01-07 11:42:45 +00:00
|
|
|
|
|
|
|
|
if test -x "$GIT_DAEMON_DOCUMENT_ROOT_PATH/$repo"
|
|
|
|
|
then
|
|
|
|
|
if test -n "$do_export"
|
|
|
|
|
then
|
|
|
|
|
: >"$GIT_DAEMON_DOCUMENT_ROOT_PATH/$repo/git-daemon-export-ok"
|
|
|
|
|
else
|
|
|
|
|
rm -f "$GIT_DAEMON_DOCUMENT_ROOT_PATH/$repo/git-daemon-export-ok"
|
|
|
|
|
fi
|
|
|
|
|
fi
|
|
|
|
|
|
2012-04-24 07:50:04 +00:00
|
|
|
test_must_fail git "$cmd" "$GIT_DAEMON_URL/$repo" "$@" 2>output &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "fatal: remote error: $msg: /$repo" output &&
|
2012-01-07 11:42:45 +00:00
|
|
|
ret=$?
|
|
|
|
|
chmod +x "$GIT_DAEMON_DOCUMENT_ROOT_PATH/repo.git"
|
|
|
|
|
(exit $ret)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
msg="access denied or repository not exported"
|
2020-11-09 00:09:24 +00:00
|
|
|
test_expect_success 'clone non-existent' "test_remote_error '$msg' clone nowhere.git"
|
2020-11-18 23:44:34 +00:00
|
|
|
test_expect_success 'push disabled' "test_remote_error '$msg' push repo.git main"
|
2020-11-09 00:09:24 +00:00
|
|
|
test_expect_success 'read access denied' "test_remote_error -x '$msg' fetch repo.git"
|
|
|
|
|
test_expect_success 'not exported' "test_remote_error -n '$msg' fetch repo.git"
|
2012-01-07 11:42:45 +00:00
|
|
|
|
|
|
|
|
stop_git_daemon
|
|
|
|
|
start_git_daemon --informative-errors
|
|
|
|
|
|
2020-11-09 00:09:24 +00:00
|
|
|
test_expect_success 'clone non-existent' "test_remote_error 'no such repository' clone nowhere.git"
|
2020-11-18 23:44:34 +00:00
|
|
|
test_expect_success 'push disabled' "test_remote_error 'service not enabled' push repo.git main"
|
2020-11-09 00:09:24 +00:00
|
|
|
test_expect_success 'read access denied' "test_remote_error -x 'no such repository' fetch repo.git"
|
|
|
|
|
test_expect_success 'not exported' "test_remote_error -n 'repository not exported' fetch repo.git"
|
2012-01-07 11:42:45 +00:00
|
|
|
|
2015-02-17 08:40:57 +00:00
|
|
|
stop_git_daemon
|
|
|
|
|
start_git_daemon --interpolated-path="$GIT_DAEMON_DOCUMENT_ROOT_PATH/%H%D"
|
|
|
|
|
|
|
|
|
|
test_expect_success 'access repo via interpolated hostname' '
|
|
|
|
|
repo="$GIT_DAEMON_DOCUMENT_ROOT_PATH/localhost/interp.git" &&
|
|
|
|
|
git init --bare "$repo" &&
|
|
|
|
|
git push "$repo" HEAD &&
|
|
|
|
|
>"$repo"/git-daemon-export-ok &&
|
|
|
|
|
GIT_OVERRIDE_VIRTUAL_HOST=localhost \
|
2018-01-25 00:55:05 +00:00
|
|
|
git ls-remote "$GIT_DAEMON_URL/interp.git" &&
|
2015-02-17 08:40:57 +00:00
|
|
|
GIT_OVERRIDE_VIRTUAL_HOST=LOCALHOST \
|
2018-01-25 00:55:05 +00:00
|
|
|
git ls-remote "$GIT_DAEMON_URL/interp.git"
|
2015-02-17 08:40:57 +00:00
|
|
|
'
|
|
|
|
|
|
daemon: sanitize incoming virtual hostname
We use the daemon_avoid_alias function to make sure that the
pathname the user gives us is sane. However, after applying
that check, we might then interpolate the path using a
string given by the server admin, but which may contain more
untrusted data from the client. We should be sure to
sanitize this data, as well.
We cannot use daemon_avoid_alias here, as it is more strict
than we need in requiring a leading '/'. At the same time,
we can be much more strict here. We are interpreting a
hostname, which should not contain slashes or excessive runs
of dots, as those things are not allowed in DNS names.
Note that in addition to cleansing the hostname field, we
must check the "canonical hostname" (%CH) as well as the
port (%P), which we take as a raw string. For the canonical
hostname, this comes from an actual DNS lookup on the
accessed IP, which makes it a much less likely vector for
problems. But it does not hurt to sanitize it in the same
way. Unfortunately we cannot test this case easily, as it
would involve a custom hostname lookup.
We do not need to check %IP, as it comes straight from
inet_ntop, so must have a sane form.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-17 19:09:24 +00:00
|
|
|
test_expect_success 'hostname cannot break out of directory' '
|
|
|
|
|
repo="$GIT_DAEMON_DOCUMENT_ROOT_PATH/../escape.git" &&
|
|
|
|
|
git init --bare "$repo" &&
|
|
|
|
|
git push "$repo" HEAD &&
|
|
|
|
|
>"$repo"/git-daemon-export-ok &&
|
|
|
|
|
test_must_fail \
|
|
|
|
|
env GIT_OVERRIDE_VIRTUAL_HOST=.. \
|
2018-01-25 00:55:05 +00:00
|
|
|
git ls-remote "$GIT_DAEMON_URL/escape.git"
|
daemon: sanitize incoming virtual hostname
We use the daemon_avoid_alias function to make sure that the
pathname the user gives us is sane. However, after applying
that check, we might then interpolate the path using a
string given by the server admin, but which may contain more
untrusted data from the client. We should be sure to
sanitize this data, as well.
We cannot use daemon_avoid_alias here, as it is more strict
than we need in requiring a leading '/'. At the same time,
we can be much more strict here. We are interpreting a
hostname, which should not contain slashes or excessive runs
of dots, as those things are not allowed in DNS names.
Note that in addition to cleansing the hostname field, we
must check the "canonical hostname" (%CH) as well as the
port (%P), which we take as a raw string. For the canonical
hostname, this comes from an actual DNS lookup on the
accessed IP, which makes it a much less likely vector for
problems. But it does not hurt to sanitize it in the same
way. Unfortunately we cannot test this case easily, as it
would involve a custom hostname lookup.
We do not need to check %IP, as it comes straight from
inet_ntop, so must have a sane form.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-17 19:09:24 +00:00
|
|
|
'
|
|
|
|
|
|
daemon: fix length computation in newline stripping
When git-daemon gets a pktline request, we strip off any
trailing newline, replacing it with a NUL. Clients prior to
5ad312bede (in git v1.4.0) would send:
git-upload-pack repo.git\n
and we need to strip it off to understand their request.
After 5ad312bede, we send the host attribute but no newline,
like:
git-upload-pack repo.git\0host=example.com\0
Both of these are parsed correctly by git-daemon. But if
some client were to combine the two:
git-upload-pack repo.git\n\0host=example.com\0
we don't parse it correctly. The problem is that we use the
"len" variable to record the position of the NUL separator,
but then decrement it when we strip the newline. So we start
with:
git-upload-pack repo.git\n\0host=example.com\0
^-- len
and end up with:
git-upload-pack repo.git\0\0host=example.com\0
^-- len
This is arguably correct, since "len" tells us the length of
the initial string, but we don't actually use it for that.
What we do use it for is finding the offset of the extended
attributes; they used to be at len+1, but are now at len+2.
We can solve that by just leaving "len" where it is. We
don't have to care about the length of the shortened string,
since we just treat it like a C string.
No version of Git ever produced such a string, but it seems
like the daemon code meant to handle this case (and it seems
like a reasonable thing for somebody to do in a 3rd-party
implementation).
Reported-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-25 00:58:54 +00:00
|
|
|
test_expect_success FAKENC 'hostname interpolation works after LF-stripping' '
|
|
|
|
|
{
|
tests: fix broken &&-chains in `{...}` groups
The top-level &&-chain checker built into t/test-lib.sh causes tests to
magically exit with code 117 if the &&-chain is broken. However, it has
the shortcoming that the magic does not work within `{...}` groups,
`(...)` subshells, `$(...)` substitutions, or within bodies of compound
statements, such as `if`, `for`, `while`, `case`, etc. `chainlint.sed`
partly fills in the gap by catching broken &&-chains in `(...)`
subshells, but bugs can still lurk behind broken &&-chains in the other
cases.
Fix broken &&-chains in `{...}` groups in order to reduce the number of
possible lurking bugs.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Reviewed-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-09 05:11:08 +00:00
|
|
|
printf "git-upload-pack /interp.git\n\0host=localhost" | packetize_raw &&
|
daemon: fix length computation in newline stripping
When git-daemon gets a pktline request, we strip off any
trailing newline, replacing it with a NUL. Clients prior to
5ad312bede (in git v1.4.0) would send:
git-upload-pack repo.git\n
and we need to strip it off to understand their request.
After 5ad312bede, we send the host attribute but no newline,
like:
git-upload-pack repo.git\0host=example.com\0
Both of these are parsed correctly by git-daemon. But if
some client were to combine the two:
git-upload-pack repo.git\n\0host=example.com\0
we don't parse it correctly. The problem is that we use the
"len" variable to record the position of the NUL separator,
but then decrement it when we strip the newline. So we start
with:
git-upload-pack repo.git\n\0host=example.com\0
^-- len
and end up with:
git-upload-pack repo.git\0\0host=example.com\0
^-- len
This is arguably correct, since "len" tells us the length of
the initial string, but we don't actually use it for that.
What we do use it for is finding the offset of the extended
attributes; they used to be at len+1, but are now at len+2.
We can solve that by just leaving "len" where it is. We
don't have to care about the length of the shortened string,
since we just treat it like a C string.
No version of Git ever produced such a string, but it seems
like the daemon code meant to handle this case (and it seems
like a reasonable thing for somebody to do in a 3rd-party
implementation).
Reported-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-25 00:58:54 +00:00
|
|
|
printf "0000"
|
|
|
|
|
} >input &&
|
|
|
|
|
fake_nc "$GIT_DAEMON_HOST_PORT" <input >output &&
|
|
|
|
|
depacketize <output >output.raw &&
|
|
|
|
|
|
2020-11-18 23:44:34 +00:00
|
|
|
# just pick out the value of main, which avoids any protocol
|
daemon: fix length computation in newline stripping
When git-daemon gets a pktline request, we strip off any
trailing newline, replacing it with a NUL. Clients prior to
5ad312bede (in git v1.4.0) would send:
git-upload-pack repo.git\n
and we need to strip it off to understand their request.
After 5ad312bede, we send the host attribute but no newline,
like:
git-upload-pack repo.git\0host=example.com\0
Both of these are parsed correctly by git-daemon. But if
some client were to combine the two:
git-upload-pack repo.git\n\0host=example.com\0
we don't parse it correctly. The problem is that we use the
"len" variable to record the position of the NUL separator,
but then decrement it when we strip the newline. So we start
with:
git-upload-pack repo.git\n\0host=example.com\0
^-- len
and end up with:
git-upload-pack repo.git\0\0host=example.com\0
^-- len
This is arguably correct, since "len" tells us the length of
the initial string, but we don't actually use it for that.
What we do use it for is finding the offset of the extended
attributes; they used to be at len+1, but are now at len+2.
We can solve that by just leaving "len" where it is. We
don't have to care about the length of the shortened string,
since we just treat it like a C string.
No version of Git ever produced such a string, but it seems
like the daemon code meant to handle this case (and it seems
like a reasonable thing for somebody to do in a 3rd-party
implementation).
Reported-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-25 00:58:54 +00:00
|
|
|
# particulars
|
2020-11-18 23:44:34 +00:00
|
|
|
perl -lne "print \$1 if m{^(\\S+) refs/heads/main}" <output.raw >actual &&
|
|
|
|
|
git -C "$repo" rev-parse main >expect &&
|
daemon: fix length computation in newline stripping
When git-daemon gets a pktline request, we strip off any
trailing newline, replacing it with a NUL. Clients prior to
5ad312bede (in git v1.4.0) would send:
git-upload-pack repo.git\n
and we need to strip it off to understand their request.
After 5ad312bede, we send the host attribute but no newline,
like:
git-upload-pack repo.git\0host=example.com\0
Both of these are parsed correctly by git-daemon. But if
some client were to combine the two:
git-upload-pack repo.git\n\0host=example.com\0
we don't parse it correctly. The problem is that we use the
"len" variable to record the position of the NUL separator,
but then decrement it when we strip the newline. So we start
with:
git-upload-pack repo.git\n\0host=example.com\0
^-- len
and end up with:
git-upload-pack repo.git\0\0host=example.com\0
^-- len
This is arguably correct, since "len" tells us the length of
the initial string, but we don't actually use it for that.
What we do use it for is finding the offset of the extended
attributes; they used to be at len+1, but are now at len+2.
We can solve that by just leaving "len" where it is. We
don't have to care about the length of the shortened string,
since we just treat it like a C string.
No version of Git ever produced such a string, but it seems
like the daemon code meant to handle this case (and it seems
like a reasonable thing for somebody to do in a 3rd-party
implementation).
Reported-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-25 00:58:54 +00:00
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
2012-01-07 11:42:45 +00:00
|
|
|
test_done
|