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

Re: What's cooking in git.git (Jan 2017, #02; Sun, 15)

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 17, 2017, 19:17 UTC
Message-ID
<xmqqo9z5fqdj.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<20170116214411.a6wnp66vxydmpmgw@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 19 quoted lines
> On Mon, Jan 16, 2017 at 09:33:07PM +0100, Johannes Sixt wrote:
>
>> However, Jeff's patch is intended to catch exactly these cases (not for the
>> cases where this happens accidentally, but when they happen with malicious
>> intent).
>> 
>> We are talking about user-provided data that is reproduced by die() or
>> error(). I daresay that we do not have a single case where it is intended
>> that this data is intentionally multi-lined, like a commit message. It can
>> only be an accident or malicious when it spans across lines.
>> 
>> I know we allow CR and LF in file names, but in all cases where such a name
>> appears in an error message, it is *not important* that the data is
>> reproduced exactly. On the contrary, it is usually more helpful to know that
>> something strange is going on. The question marks are a strong indication to
>> the user for this.
>
> Yes, exactly. Thanks for explaining this better than I obviously was
> doing. :)

Yup. In the "funny filename" case, the updated code indeed is doing the right thing. So one remaining possible issue is if we ourselves deliberately feed a raw CR (or any non-filtered control code) to error() and friends because their native effect (like returning the carriage to overwrite what we have already said with the remainder of the message by using CR) to functions that go through vreportf() interface. I personally do not think there is any---the progress meter code does use CR for that but they don't do vreportf().

I do not think we write "message\r\n" even for Windows; we rely on vfprintf() and other stdio layer to turn "message\n" into "message\r\n" before it hits write(2) or its equivalent? So I understand that this should affect LF and CRLF systems the same way (meaning, no negative effect).

So... can we move this forward?
Previous: Jeff KingNext: Johannes Sixt
Message 9 of 28 in “What's cooking in git.git (Jan 2017, #02; Sun, 15)”
  1. Junio C HamanoJan 16, 2017
  2. Johannes SixtJan 16, 2017
  3. Junio C HamanoJan 16, 2017
  4. Johannes SchindelinJan 16, 2017
  5. Jeff KingJan 16, 2017
  6. Johannes SchindelinJan 16, 2017
  7. Johannes SixtJan 16, 2017
  8. Jeff KingJan 16, 2017
  9. Junio C HamanoJan 17, 2017
  10. Johannes SixtJan 18, 2017
  11. Junio C HamanoJan 18, 2017
  12. Johannes SchindelinJan 19, 2017
  13. Jeff KingJan 16, 2017
  14. CodingGuidelines: clarify multi-line brace styleJeff King, Jan 16, 2017
  15. Junio C HamanoJan 17, 2017
  16. Jeff KingJan 17, 2017
  17. Junio C HamanoJan 17, 2017
  18. Jacob KellerJan 17, 2017
  19. Jeff KingJan 17, 2017
  20. Junio C HamanoJan 17, 2017
  21. Jeff KingJan 17, 2017
  22. Junio C HamanoJan 17, 2017
  23. Jeff KingJan 17, 2017
  24. Johannes SchindelinJan 16, 2017
  25. Junio C HamanoJan 17, 2017
  26. Johannes SchindelinJan 18, 2017
  27. Johannes SchindelinJan 16, 2017
  28. 4/4 unpack-trees: support super-prefix optionStefan Beller, Jan 18, 2017

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.