[PATCH 0/6] better handling of gigantic config files

The fact that parse_config_key() requires its callers to use an "int" for a string length has bugged me for a while, and it re-bugged me when looking at it today. So I finally decided to do something about it, which led to an odyssey of other small fixes and cleanups.

In particular, I was curious what kinds of bad behavior you could provoke by having a key name larger than 2GB (especially because we use the same parser for .gitmodules files, which might not be trusted). It turns out: basically none, because the config parser chokes immediately dues to its own int/size_t confusion.

After patch 5, the config system _can_ actually handle stupidly-sized config keys, but in the end I decided to explicitly disallow them. There's downstream code that would be impossible to fix, and nobody actually cares about this case working anyway. See patch 6 for more discussion. I do still think the other patches are worth having as a cleanup; the more code that is safe from unexpected integer truncation the better.

  [1/6]: remote: drop auto-strlen behavior of make_branch() and make_rewrite()
  [2/6]: parse_config_key(): return subsection len as size_t
  [3/6]: config: drop useless length variable in write_pair()
  [4/6]: git_config_parse_key(): return baselen as size_t
  [5/6]: config: use size_t to store parsed variable baselen
  [6/6]: config: reject parsing of files over INT_MAX

 archive-tar.c      |  4 ++--
 builtin/help.c     |  2 +-
 builtin/reflog.c   |  2 +-
 config.c           | 42 +++++++++++++++++++++++++++++-------------
 config.h           |  4 ++--
 convert.c          |  2 +-
 fsck.c             |  2 +-
 ll-merge.c         |  2 +-
 promisor-remote.c  |  2 +-
 remote.c           | 37 +++++++++++++------------------------
 submodule-config.c |  3 ++-
 userdiff.c         |  4 ++--
 12 files changed, 56 insertions(+), 50 deletions(-)

-Peff