All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Cahyna <pcahyna@redhat.com>
To: Jeff King <peff@peff.net>
Cc: Sebastian Kisela <skisela@redhat.com>,
	git@vger.kernel.org, nico@fluxnic.net, larsxschneider@gmail.com,
	lfleischer@lfos.de
Subject: Re: [PATCH] Sanitize escape char sequences coming from server
Date: Thu, 21 Jun 2018 20:09:43 +0200	[thread overview]
Message-ID: <20180621180942.GA32506@redhat.com> (raw)
In-Reply-To: <20180621174122.GA30249@sigill.intra.peff.net>

Hello,

On Thu, Jun 21, 2018 at 01:41:22PM -0400, Jeff King wrote:
> 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.

> > +	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*()

> 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

  reply	other threads:[~2018-06-21 18:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-21 12:10 [PATCH] Sanitize escape char sequences coming from server Sebastian Kisela
2018-06-21 17:41 ` Jeff King
2018-06-21 18:09   ` Pavel Cahyna [this message]
2018-06-21 18:51     ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180621180942.GA32506@redhat.com \
    --to=pcahyna@redhat.com \
    --cc=git@vger.kernel.org \
    --cc=larsxschneider@gmail.com \
    --cc=lfleischer@lfos.de \
    --cc=nico@fluxnic.net \
    --cc=peff@peff.net \
    --cc=skisela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.