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
next prev parent 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).