Re: [PATCH 1/2] gitweb: esc_html (short) error message in die_error

From: Jakub Narebski <jnareb@gmail.com>
Date: Feb 17, 2010, 16:21 UTC
Message-ID: <201002171721.17339.jnareb@gmail.com>
In-Reply-To: <20100207204803.11146.57731.stgit@localhost.localdomain>

On Sun, 7 Feb 2010, Jakub Narebski wrote:

Show 23 quoted lines

> 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