git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Subject: Re: [PATCH] gitweb: Consolidate escaping/validation of query string
Date: Sun, 24 Sep 2006 00:36:13 +0200	[thread overview]
Message-ID: <ef4csl$7vk$1@sea.gmane.org> (raw)
In-Reply-To: 20060923221841.18063.56589.stgit@rover

Petr Baudis wrote:

> Consider:
> 
>         http://repo.or.cz/?p=glibc-cvs.git;a=tree;h=2609cb0411389325f4ee2854cc7159756eb0671e;hb=2609cb0411389325f4ee2854cc7159756eb0671e
> 
> (click on the funny =__ify file)

Aaargh? Why this name?

> We ought to handle anything in filenames and I actually see no reason why
> we don't, modulo very little missing escaping that this patch hopefully
> also fixes.
> 
> I have also made esc_param() escape [?=&;]. Not escaping [&;] was downright
> buggy and [?=] just feels better escaped. ;-) YMMV.

First of all, before introduction href() subroutine we escaped (using 
esc_param) the _whole_ generated query string. Now we need to escape
only value part (as we can assume that parameter names are correct;
they are taken from limited pre-defined set).

I'd rather have new esc_param() or esc_param_value() quote like escape
subroutine from CGI::Util, with the esception of _not_ escaping '/'
(it makes funny bookmark, and lot less readable query string), and rename
current esc_param() to esc_query_string() or esc_params().

Perhaps we should have also esc_arg() for things like title attribute
of <a> (link) element (or other element) and filename="..." part of
Content-disposition: HTTP header.


By the way, the validate_input() should be split into separate subroutines:
validate_ref() for validating hash, hash_base, hash_parent, hash_parent_base,
and validate_path() for validating project, file_name and file_parent
parameters.

We should _never_ use esc_html except during the output, or just before output.
It certainly shouldn't take place in parse_* subroutine (or in the fake parse
like in git_blobdiff)!

P.S. gitweb was tested I think with filenames wirh spaces. Perhaps we should
add some other test file to gitweb/test, with '=', '@', '$', '?', '*', ' ', '\n'
etc.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

  reply	other threads:[~2006-09-23 22:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-23 22:18 [PATCH] gitweb: Consolidate escaping/validation of query string Petr Baudis
2006-09-23 22:36 ` Jakub Narebski [this message]
2006-09-23 22:41   ` Jakub Narebski
2006-09-24 11:36   ` Petr Baudis
2006-09-24 12:21     ` Jakub Narebski
2006-09-24 11:39   ` Petr Baudis
2006-09-24 12:31     ` 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='ef4csl$7vk$1@sea.gmane.org' \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).