diff options
author | Jeff King <peff@peff.net> | 2018-07-13 15:39:53 -0400 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2018-07-16 10:57:22 -0700 |
commit | 0d68764d94958aece0355d5d27f383e7d4de2e58 (patch) | |
tree | 3eacc406bd62482325429497bfd743e2e486697f /contrib/README | |
parent | fsck: silence stderr when parsing .gitmodules (diff) | |
download | tgif-0d68764d94958aece0355d5d27f383e7d4de2e58.tar.xz |
fsck: split ".gitmodules too large" error from parse failure
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@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'contrib/README')
0 files changed, 0 insertions, 0 deletions