From: Jakub Narebski <jnareb@gmail.com>
Date: Mon, 06 Sep 2010 16:31:58 GMT
Subject: Re: [PATCH] Add ERR support to smart HTTP
Message-ID: <201009061832.00512.jnareb@gmail.com>
In-Reply-To: <AANLkTi=jqpspQvz6--CGfVEpP8raD7RpNGgMs6KabXfS@mail.gmail.com>

Sitaram Chamarty wrote:
> On Mon, Sep 6, 2010 at 2:19 PM, Jakub Narebski <jnareb@gmail.com> wrote:

> > Nevertheless I think it would be a good idea to make *client* more
> > accepting, which means:
> > 1. Printing full HTTP status, and not only HTTP return / error code;
> >   perhaps only if it is non-standard, and perhaps only in --verbose
> >   mode.
> > 2. If message body contains ERR line, print error message even if the
> >   HTTP status was other than "200 OK".  To be "generous in what you
> >   receive" (well, kind of).
> > 3. In verbose mode, if body of HTTP error message (not "HTTP OK")
> >   exists and does not contain ERR line (e.g. an error from web server),
> >   print it in full (perhaps indented).
> >
> > I think that neither of the above would lead to leaking sensitive
> > information.
> 
> I didn't understand this bit about leaking info.  If the bits are
> coming into my machine I know what they are anyway (or am able to find
> out easily enough, even if git itself isn't showing them to me).
> Where's the leak?

I meant here that programs (including git) do not provide full details
about error condition, especially if it has to do womething with 
authentication, to avoid leaking sensitive information (like e.g. 
saying that username + password combination is invalid, instead of
telling which one is wrong, to avoid disclosing usernames).

-- 
Jakub Narebski
Poland