git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 6/6] config: reject parsing of files over INT_MAX

From
Taylor Blau <me@ttaylorr.com>
Date
Apr 13, 2020, 00:47 UTC
Message-ID
<20200413004724.GB55122@syl.local>
In-Reply-To
<20200410221549.GA2078378@coredump.intra.peff.net>
On Fri, Apr 10, 2020 at 06:15:49PM -0400, Jeff King wrote:
Show 31 quoted lines
> On Fri, Apr 10, 2020 at 03:04:31PM -0700, Junio C Hamano wrote:
>
> > Jeff King <peff@peff.net> writes:
> >
> > > So given the fact that these are insane cases which we have no need to
> > > support, the weird behavior from feeding the results to printf even if
> > > the code is careful, and the possibility of uncareful code introducing
> > > its own integer truncation issues, let's just declare INT_MAX as a limit
> > > for parsing config files.
> >
> > Makes sense.
> >
> > > +	if (c != EOF && ++cf->total_len > INT_MAX) {
> >
> > Would this work correctly if size_t is uint?  Sure, as int-max would
> > fit within it.  And of course if size_t is wider than uint, there is
> > no problem in this comparison.
>
> Good question, but yeah, I think it's right.
>
> Another method would be to do:
>
>   if (cf->total_len >= INT_MAX)
>
> _before_ reading any character. We'd have to remember to increment
> total_len then (I suppose we could do it preemptively; as long as people
> don't try to read EOF from us over and over again it would never move
> again).
>
> I also considered making the limit much lower than INT_MAX because
> really, who needs even a 1GB config file? :)

;). Making it lower than INT_MAX moves us into the territory of deciding what is an "appropriately" sized config file, which I'd rather not do. At least we can blame INT_MAX if someone has a too-large config file.

> -Peff

Thanks, Taylor

Previous: Jeff KingNext: Junio C Hamano
Message 12 of 16 in “better handling of gigantic config files”
  1. 0/6 better handling of gigantic config filesJeff King, Apr 10, 2020
  2. 1/6 remote: drop auto-strlen behavior of make_branch() and make_rewrite()Jeff King, Apr 10, 2020
  3. Junio C HamanoApr 10, 2020
  4. 2/6 parse_config_key(): return subsection len as size_tJeff King, Apr 10, 2020
  5. 3/6 config: drop useless length variable in write_pair()Jeff King, Apr 10, 2020
  6. Junio C HamanoApr 10, 2020
  7. 4/6 git_config_parse_key(): return baselen as size_tJeff King, Apr 10, 2020
  8. 5/6 config: use size_t to store parsed variable baselenJeff King, Apr 10, 2020
  9. 6/6 config: reject parsing of files over INT_MAXJeff King, Apr 10, 2020
  10. Junio C HamanoApr 10, 2020
  11. Jeff KingApr 10, 2020
  12. Taylor BlauApr 13, 2020
  13. Junio C HamanoApr 13, 2020
  14. Taylor BlauApr 13, 2020
  15. Jeff KingApr 13, 2020
  16. Taylor BlauApr 13, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.