git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Tom Preston-Werner" <tom@github.com>
To: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Cc: "Nicolas Pitre" <nico@cam.org>, git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH] connect.c: add a way for git-daemon to pass an error back to client
Date: Fri, 31 Oct 2008 20:35:20 -0700	[thread overview]
Message-ID: <b97024a40810312035v5416b578v51b5bed528ca8d39@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.1.00.0811010334010.22125@pacific.mpi-cbg.de.mpi-cbg.de>

On Fri, Oct 31, 2008 at 7:35 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 31 Oct 2008, Nicolas Pitre wrote:
>
>> On Sat, 1 Nov 2008, Johannes Schindelin wrote:
>>
>> > On Fri, 31 Oct 2008, Tom Preston-Werner wrote:
>> >
>> > > The current behavior of git-daemon is to simply close the connection
>> > > on any error condition. This leaves the client without any
>> > > information as to the cause of the failed fetch/push/etc.
>> > >
>> > > This patch allows get_remote_heads to accept a line prefixed with
>> > > "ERR" that it can display to the user in an informative fashion.
>> > > Once clients can understand this ERR line, git-daemon can be made to
>> > > properly report "repository not found", "permission denied", or
>> > > other errors.
>> > >
>> > > Example
>> > >
>> > > S: ERR No matching repository.
>> > > C: fatal: remote error: No matching repository.
>> >
>> > Makes sense to me.
>>
>> Note that this behavior of not returning any reason for failure was
>> argued to be a security feature in the past, by Linus I think.
>
> Yes.  And it might still be considered one.  You do not need to patch
> git-daemon to use that facility (note that Tom's patch was only for the
> client side).
>
> But for hosting sites such as repo.or.cz or GitHub, that security feature
> just does not make sense, but it makes for support requests that could be
> resolved better with a proper error message.

We could also have the error messages sent back conditionally based on
a command line switch. I've begun porting the changes I made in our
Erlang git-daemon back to the C code, so maybe I'll give that a try.
We *definitely* need good error messages for GitHub and I see no
security risk in doing so.

Maybe this is worth asking the question: does anybody use git-daemon
for private code? If so, why are they not using SSH instead? And in
that case, how are informative error messages a security risk?

Tom

  reply	other threads:[~2008-11-01  3:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-01  1:59 [PATCH] connect.c: add a way for git-daemon to pass an error back to client Tom Preston-Werner
2008-11-01  2:19 ` Johannes Schindelin
2008-11-01  2:18   ` Tom Preston-Werner
2008-11-01  2:20   ` Nicolas Pitre
2008-11-01  2:35     ` Johannes Schindelin
2008-11-01  3:35       ` Tom Preston-Werner [this message]
2008-11-01 11:34         ` Andreas Ericsson
2008-11-01 14:39         ` Alex Riesen
2008-11-01 11:30     ` Andreas Ericsson
2008-11-01  5:39 ` Junio C Hamano
2008-11-01  6:29   ` Tom Preston-Werner
2008-11-01 18:10     ` Shawn O. Pearce
2008-11-01 22:48     ` Junio C Hamano

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=b97024a40810312035v5416b578v51b5bed528ca8d39@mail.gmail.com \
    --to=tom@github.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=nico@cam.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).