Since ed8b10f631 (fsck: check .gitmodules content, 2018-05-02), we'll report a gitmodulesParse error for two conditions: - a .gitmodules entry is not syntactically valid - a .gitmodules entry is larger than core.bigFileThreshold with the intent that we can detect malicious files and protect downstream clients. E.g., from the issue in 0383bbb901 (submodule-config: verify submodule names as paths, 2018-04-30). But these conditions are actually quite different with respect to that bug: - a syntactically invalid file cannot trigger the problem, as the victim would barf before hitting the problematic code - a too-big .gitmodules _can_ trigger the problem. Even though it is obviously silly to have a 500MB .gitmodules file, the submodule code will happily parse it if you have enough memory. So it may be reasonable to configure their severity separately. Let's add a new class for the "too large" case to allow that. Signed-off-by: Jeff King <peff@xxxxxxxx> --- fsck.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fsck.c b/fsck.c index 87b0e228bd..4129935d86 100644 --- a/fsck.c +++ b/fsck.c @@ -63,6 +63,7 @@ static struct oidset gitmodules_done = OIDSET_INIT; FUNC(GITMODULES_MISSING, ERROR) \ FUNC(GITMODULES_BLOB, ERROR) \ FUNC(GITMODULES_PARSE, ERROR) \ + FUNC(GITMODULES_LARGE, ERROR) \ FUNC(GITMODULES_NAME, ERROR) \ FUNC(GITMODULES_SYMLINK, ERROR) \ /* warnings */ \ @@ -1005,7 +1006,7 @@ static int fsck_blob(struct blob *blob, const char *buf, * that an error. */ return report(options, &blob->object, - FSCK_MSG_GITMODULES_PARSE, + FSCK_MSG_GITMODULES_LARGE, ".gitmodules too large to parse"); } -- 2.18.0.433.gb9621797ee
