git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: david@lang.hm
To: Andreas Ericsson <ae@op5.se>
Cc: "Shawn O. Pearce" <spearce@spearce.org>,
	"Stephen R. van den Berg" <srb@cuci.nl>,
	git <git@vger.kernel.org>
Subject: Re: [RFC] Adding a challenge-response authentication method to git://
Date: Thu, 14 Aug 2008 10:24:37 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.1.10.0808141021210.13400@asgard.lang.hm> (raw)
In-Reply-To: <48A3F7AA.8070001@op5.se>

On Thu, 14 Aug 2008, Andreas Ericsson wrote:

> I'd do it like this instead:
>
> daemon: auth_user = dlsym(dlopen("auth-module.so", RTLD_NOW), "authenticat");
> client: "git-authenticate action 'repository'"
> daemon: send pkt-line challenge
> client: send pkt-line username
> client: send pkt-line SHA1(username + password + challenge)
> daemon: if (auth_user(repository, action, username, password, struct 
> sockaddr_in *inbound))
>              allow_connection();
>
> This approach has several nifty benefits:
> * The otherwise duplicated code (for different auth schemes) is
> done only once (in the git daemon).
> * If the git daemon has no authentication module loaded, we might
> as well not bother sending any challenge and just pretend we do
> not know about the authentication scheme.
> * Any kind of authentication scheme can be supported without changing
> the core code. If the authentication module does something wrong,
> one can continue to serve read-only requests by simply unloading
> the module.
> * Modules is a great way for newcomers to get started contributing to
> git so it's a nice way of getting more contributors/sub-maintainers.

if you're going to do modules, you should give the module the connection 
until it's done so that different types of authentication can be 
implemented by the module.

David Lang

  parent reply	other threads:[~2008-08-14 17:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-13 16:26 [RFC] Adding a challenge-response authentication method to git:// Stephen R. van den Berg
2008-08-13 16:36 ` Petr Baudis
2008-08-14  7:48   ` David Brown
2008-08-14  8:23     ` Petr Baudis
2008-08-14 11:07       ` Stephen R. van den Berg
2008-08-14 11:39         ` Petr Baudis
2008-08-14 12:14           ` Stephen R. van den Berg
2008-08-13 16:40 ` Shawn O. Pearce
2008-08-13 17:37   ` Stephen R. van den Berg
2008-08-13 18:08     ` Shawn O. Pearce
2008-08-14  0:10       ` Stephen R. van den Berg
2008-08-14  0:57         ` Shawn O. Pearce
2008-08-14  7:13           ` Stephen R. van den Berg
2008-08-14  9:15           ` Andreas Ericsson
2008-08-14  9:51             ` Stephen R. van den Berg
2008-08-14 17:24             ` david [this message]
2008-08-14 17:18   ` david
2008-08-14 21:00     ` Shawn O. Pearce

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=alpine.DEB.1.10.0808141021210.13400@asgard.lang.hm \
    --to=david@lang.hm \
    --cc=ae@op5.se \
    --cc=git@vger.kernel.org \
    --cc=spearce@spearce.org \
    --cc=srb@cuci.nl \
    /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).