All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] gitweb: filter escapes from longer commit titles that break firefox
Date: Mon, 20 Apr 2009 09:29:15 -0400	[thread overview]
Message-ID: <49EC78AB.6020009@windriver.com> (raw)
In-Reply-To: <m3r5znpt5g.fsf@localhost.localdomain>

Jakub Narebski wrote:
> Paul Gortmaker <paul.gortmaker@windriver.com> writes:
>
>   
>> If there is a commit that ends in ^X and is longer in length than
>> what will fit in title_short, then it doesn't get fed through
>> esc_html() and so the ^X will appear as-is in the page source.
>>
>> When Firefox comes across this, it will fail to display the page,
>> and only display a couple lines of error messages that read like:
>>
>>    XML Parsing Error: not well-formed
>>    Location: http://git ....
>>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>>     
>
> This is an issue for when project doesn't follow sanity (control
> characters in commit message) nor commit message conventions of git
> (limiting length of first line of commit message to 60-70 characters).
>   

I agree - the situation should be that it doesn't happen, but it can 
happen (and it did
happen) that a novice, or a simple mistake ends up with such a commit. 

> But I do not think that the solution presented here is good solution
> for this problem.  chop_and_escape_str is meant as _output_ filter,
> because it generates (can generate) fragment of HTML.  It is not a
> good solution to use it for shortening in intermediate representation
> of %co{'title'}.
>
> And I think that issue might be a bug elsewhere in gitweb if we have
> text output which is not passed through esc_html... or bug in CGI.pm
> if the error is in not escaping of -title _attribute_ (attribute
> escaping has slightly different rules than escaping HTML, and should
> be done automatically by CGI.pm).
>
>
> So thanks for noticing the issue, but NAK on the solution.
>   

Fair enough -- I wasn't familiar with the code in there, and there 
wasn't really any indication that it was for output only.  I can easily 
believe that there is a better place for it -- I just didn't see where 
any global esc_html filtering was taking place...

Paul.

>   
>> ---
>>  gitweb/gitweb.perl |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index 33ef190..e686e82 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -2470,7 +2470,7 @@ sub parse_commit_text {
>>  	foreach my $title (@commit_lines) {
>>  		$title =~ s/^    //;
>>  		if ($title ne "") {
>> -			$co{'title'} = chop_str($title, 80, 5);
>> +			$co{'title'} = chop_and_escape_str($title, 80, 5);
>>  			# remove leading stuff of merges to make the interesting part visible
>>  			if (length($title) > 50) {
>>  				$title =~ s/^Automatic //;
>> -- 
>> 1.6.2.3
>>
>>     
>
>   

  reply	other threads:[~2009-04-20 13:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-17 16:24 [PATCH] gitweb: filter escapes from longer commit titles that break firefox Paul Gortmaker
2009-04-20  9:32 ` Jakub Narebski
2009-04-20 13:29   ` Paul Gortmaker [this message]
2009-04-24 17:53     ` Jakub Narebski
2009-04-24 19:48       ` Paul Gortmaker
2009-04-24 22:10         ` Jakub Narebski
2009-04-25  9:04           ` Jakub Narebski

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=49EC78AB.6020009@windriver.com \
    --to=paul.gortmaker@windriver.com \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.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.