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 1/2] gitweb: esc_html (short) error message in die_error
Date: Wed, 17 Feb 2010 17:21:16 +0100	[thread overview]
Message-ID: <201002171721.17339.jnareb@gmail.com> (raw)
In-Reply-To: <20100207204803.11146.57731.stgit@localhost.localdomain>

On Sun, 7 Feb 2010, Jakub Narebski wrote:

> The error message (second argument to die_error) is meant to be short,
> one-line text description of given error.  A few callers call
> die_error with error message containing unescaped user supplied data
> ($hash, $file_name).  Instead of forcing callers to escape data,
> simply call esc_html on the parameter.
> 
> Note that optional third parameter, which contains detailed error
> description, is meant to be HTML formatted, and therefore should be
> not escaped.
> 
> While at it update esc_html synopsis/usage, and bring default error
> description to read 'Internal Server Error' (titlecased).
> 
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> Alternate solution would be to do escaping in call sites for die_error.
> 
> But in error messages shown on 'die' via CGI::Carp qw(fatalsToBrowser)
> the error message is HTML escaped, so in fact we are following here
> this "calling convention".
> 
> Note that for any patch relied on 'Internal server error' as error
> message, it must be changed to not fail wrongly.

Ping!

On one hand it introduces different treatment for second parameter to
die_error (error message), which is now being HTML-escaped, and optional
third parameter to die_error (detailed description), which is taken as
formatted and not escaped.  On the other hand this is simple solution
not requiring changes in callsites, and allowing easy extending error
messages with relevant information.

Another related issue is how detailed should be our one-line error
messages, and what data should they include.  User provided input
($file_name, $hash, etc.) should be safe if HTML-escaped.  But what
about adding errno message: "$!"?  It can help in debugging the
problem, but theoretically it exposes information to a possible
attacker...

What do you think about it?
-- 
Jakub Narebski
Poland

  reply	other threads:[~2010-02-17 16:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-07 20:47 [PATCH 0/2] gitweb: Improve escaping Jakub Narebski
2010-02-07 20:51 ` [PATCH 1/2] gitweb: esc_html (short) error message in die_error Jakub Narebski
2010-02-17 16:21   ` Jakub Narebski [this message]
2010-02-07 20:52 ` [PATCH 2/2] gitweb: Protect escaping functions against calling on undef Jakub Narebski
2010-02-17 16:26   ` 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=201002171721.17339.jnareb@gmail.com \
    --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).