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

Re: [PATCH 2/4] receive-pack: implement advertising and receiving push options

From
Jeff King <peff@peff.net>
Date
Jul 8, 2016, 22:35 UTC
Message-ID
<20160708223533.GA11056@sigill.intra.peff.net>
In-Reply-To
<CAGZ79kbu1ec-8LiFrvnXqFqsjFnEofhjZnxcENa1aA1K56m9Fg@mail.gmail.com>
On Fri, Jul 08, 2016 at 03:29:09PM -0700, Stefan Beller wrote:
Show 37 quoted lines
> > In the malicious case, the client says "I'll send you 10 push option
> > with an upper bound of 1024K", and then sends gigabytes anyway. Either
> > way the server has to react to what is sent, not what is promised.
> 
> Well that is what the initial patch did via:
> 
> +       for (i = 0; i < max_options; i++) {
> +               char *line;
> +               int len;
> +
> +               line = packet_read_line(0, &len);
> +
> +               if (!line)
> +                       break;
> +
> +               if (len > max_size)
> +                       die("protocol error: server configuration allows push "
> +                           "options of size up to %d bytes", max_size);
> +
> +               len = strcspn(line, "\n");
> +               line[len] = '\0';
> +
> +               string_list_append(ret, line);
> +       }
> +       if (i == max_options)
> +               die("protocol error: server configuration only allows up "
> +                   "to %d push options", max_options);
> 
> I assume the die is an effective way to "stop receiving".
> 
> Thinking further about what you said, I think the initial selections of
> max_size and max_options is sufficient and we only see those bounds in
> the malicious case.
> 
> This discussion rather makes me wonder if we want to stick to the initial design
> as it was easy and not overcomplicating things as we assume the abort case
> doesn't occur often.

Yes. I haven't been following the intermediate discussion and patches, but I don't see anything wrong with the general design above. I think you do need to use rp_error() to get the die message to the client for non-ssh cases, though (that is a problem with other protocol-error messages, too; I wonder if we should install a custom die handler, or convert them all to some kind of rp_die()).

-Peff
Previous: Stefan BellerNext: Stefan Beller
Message 16 of 31 in “[PATCHv3 0/4] Push options in C Git”
  1. Stefan BellerJul 7, 2016
  2. 2/4 receive-pack: implement advertising and receiving push optionsStefan Beller, Jul 7, 2016
  3. Junio C HamanoJul 7, 2016
  4. Stefan BellerJul 7, 2016
  5. Jeff KingJul 7, 2016
  6. Stefan BellerJul 7, 2016
  7. Jeff KingJul 7, 2016
  8. Junio C HamanoJul 7, 2016
  9. Jonathan NiederJul 8, 2016
  10. Junio C HamanoJul 8, 2016
  11. Stefan BellerJul 8, 2016
  12. Jeff KingJul 8, 2016
  13. Stefan BellerJul 8, 2016
  14. Jeff KingJul 8, 2016
  15. Stefan BellerJul 8, 2016
  16. Jeff KingJul 8, 2016
  17. Stefan BellerJul 8, 2016
  18. Jeff KingJul 8, 2016
  19. Stefan BellerJul 8, 2016
  20. 3/4 push: accept push optionsStefan Beller, Jul 7, 2016
  21. Junio C HamanoJul 7, 2016
  22. Stefan BellerJul 8, 2016
  23. Junio C HamanoJul 11, 2016
  24. 1/4 push options: {pre,post}-receive hook learns about push optionsStefan Beller, Jul 7, 2016
  25. Junio C HamanoJul 7, 2016
  26. Stefan BellerJul 7, 2016
  27. Junio C HamanoJul 7, 2016
  28. 4/4 add a test for push optionsStefan Beller, Jul 7, 2016
  29. Junio C HamanoJul 7, 2016
  30. Junio C HamanoJul 7, 2016
  31. Stefan BellerJul 7, 2016

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.