aboutsummaryrefslogtreecommitdiff
path: root/thread-utils.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2013-02-20 15:01:26 -0500
committerJunio C Hamano <gitster@pobox.com>2013-02-20 13:42:21 -0800
commit090fd4fe24b9da9d912aa5856f4cd32d157924c6 (patch)
tree38bfc3c1f2b987b25fcb302721af7f2393673ebf /thread-utils.c
parent6379dd052243aa6b1cc5115b72b78aedbeeed008 (diff)
downloadgit-090fd4fe24b9da9d912aa5856f4cd32d157924c6.tar.gz
git-090fd4fe24b9da9d912aa5856f4cd32d157924c6.tar.xz
upload-archive: use argv_array to store client arguments
The current parsing scheme for upload-archive is to pack arguments into a fixed-size buffer, separated by NULs, and put a pointer to each argument in the buffer into a fixed-size argv array. This works fine, and the limits are high enough that nobody reasonable is going to hit them, but it makes the code hard to follow. Instead, let's just stuff the arguments into an argv_array, which is much simpler. That lifts the "all arguments must fit inside 4K together" limit. We could also trivially lift the MAX_ARGS limitation (in fact, we have to keep extra code to enforce it). But that would mean a client could force us to allocate an arbitrary amount of memory simply by sending us "argument" lines. By limiting the MAX_ARGS, we limit an attacker to about 4 megabytes (64 times a maximum 64K packet buffer). That may sound like a lot compared to the 4K limit, but it's not a big deal compared to what git-archive will actually allocate while working (e.g., to load blobs into memory). The important thing is that it is bounded. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'thread-utils.c')
0 files changed, 0 insertions, 0 deletions