summaryrefslogtreecommitdiff
path: root/contrib/completion/git-completion.bash
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2018-01-24 19:56:07 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2018-01-25 13:50:17 -0800
commit19136be3f874ac265195ef35a8c5ed6c417eaea2 (patch)
tree886c23399e0c8f806aa1e21cbb80b1045e6e0f79 /contrib/completion/git-completion.bash
parentt/lib-git-daemon: record daemon log (diff)
downloadtgif-19136be3f874ac265195ef35a8c5ed6c417eaea2.tar.xz
daemon: fix off-by-one in logging extended attributes
If receive a request like: git-upload-pack /foo.git\0host=localhost we mark the offset of the NUL byte as "len", and then log the bytes after the NUL with a "%.*s" placeholder, using "pktlen - len" as the length, and "line + len + 1" as the start of the string. This is off-by-one, since the start of the string skips past the separating NUL byte, but the adjusted length includes it. Fortunately this doesn't actually read past the end of the buffer, since "%.*s" will stop when it hits a NUL. And regardless of what is in the buffer, packet_read() will always add an extra NUL terminator for safety. As an aside, the git.git client sends an extra NUL after a "host" field, too, so we'd generally hit that one first, not the one added by packet_read(). You can see this in the test output which reports 15 bytes, even though the string has only 14 bytes of visible data. But the point is that even a client sending unusual data could not get us to read past the end of the buffer, so this is purely a cosmetic fix. 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>
Diffstat (limited to 'contrib/completion/git-completion.bash')
0 files changed, 0 insertions, 0 deletions