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

Re: [PATCH] Sanitize escape char sequences coming from server

From
PCPavel Cahyna <pcahyna@redhat.com>
Date
Jun 21, 2018, 18:09 UTC
Message-ID
<20180621180942.GA32506@redhat.com>
In-Reply-To
<20180621174122.GA30249@sigill.intra.peff.net>
Hello,
On Thu, Jun 21, 2018 at 01:41:22PM -0400, Jeff King wrote:
Show 9 quoted lines
> On Thu, Jun 21, 2018 at 02:10:30PM +0200, Sebastian Kisela wrote:
> 
> > From: Sebastian Kisela <skisela@redhat.com>
> > +	int len = mbstowcs(wcstring, outbuf->buf, outbuf->len);
> 
> I don't think mbstowcs() is always going to do the right thing there.
> We're looking at a string that was sent from the remote server. What
> encoding is it in? Using mbstowcs() is going to use whatever is in
> LC_CTYPE on the local machine.

Exactly. The point is, everything should continue to work if the local machine and the server agreed on the encoding. Imagine a non-English-speaking site where the administrators configured the Git server to output non-ASCII messages and the clients are configured with a matching locale which allows the users to see them. We should ensure everything keeps working in this case.

Show 13 quoted lines
> > +	for(int i = 0; i <= len; i++)
> > +		if(!isprint(wcstring[i]) && !isspace(wcstring[i]) )
> > +			wcstring[i] = '?';
> > +		if (wcstombs(outbuf->buf, wcstring, outbuf->len) == -1)
> > +			return 1;
> 
> Funny indentation. I think the second line is supposed to _not_ be in
> the loop, so this is just funny indentation and not wrong code.
> 
> Using isprint() here probably doesn't do what you expect, because Git
> uses its own locale-agnostic ctype replacements. I didn't check, but I
> suspect any non-ascii characters will be marked as non-printable, making
> the whole wchar thing pointless.
isw*() was probably intended instead of is*()
Show 15 quoted lines
> Your replacement allows existing spaces, which is good; many servers
> send carriage-returns as part of progress output (and recv_sideband
> detects these and makes sure the line remains prefixed with "remote:").
> 
> > @@ -74,6 +89,9 @@ int recv_sideband(const char *me, int in_stream, int out)
> >  				} else {
> >  					strbuf_addch(&outbuf, *brk);
> >  				}
> > +
> > +				if (sanitize_server_message(&outbuf))
> > +					retval = SIDEBAND_REMOTE_ERROR;
> 
> "outbuf" may contain partially-received lines at various points, meaning
> multi-byte characters could be cut off. I _think_ it's OK to look at it
> here, as we'd always be breaking on a "\r" or "\n" at this point.

Maybe sanitize_server_message should return a mbstate_t to keep state between invocations?

Thanks, Pavel
Previous: Jeff KingNext: Jeff King
Message 3 of 4 in “Sanitize escape char sequences coming from server”
  1. Sanitize escape char sequences coming from serverSebastian Kisela, Jun 21, 2018
  2. Jeff KingJun 21, 2018
  3. Pavel CahynaJun 21, 2018
  4. Jeff KingJun 21, 2018

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.