git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Asheesh Laroia <asheesh@asheesh.org>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [RFC] Secure central repositories by UNIX socket authentication
Date: Mon, 28 Jan 2008 22:11:05 -0500	[thread overview]
Message-ID: <20080129031105.GI24004@spearce.org> (raw)
In-Reply-To: <alpine.DEB.1.00.0801280922160.3774@alchemy.localdomain>

Asheesh Laroia <asheesh@asheesh.org> wrote:
> On Mon, 28 Jan 2008, Shawn O. Pearce wrote:
> >
> >I've had enough cases of users losing their SSH key and needing to 
> >recreate it that I'd rather not have to manage a 50 user long 
> >authorized_keys file.
> 
> For what it's worth, if you haven't seen gitosis yet, you might want to 
> take a look - at least it makes managing the keys easy. 
> http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way 
> has a nice tutorial.

Yea, I've looked at it before.  There's a few reasons I don't
use gitosis, although it does look to be an excellent chunk of
Git automation:

* Its access controls aren't as powerful

  Frankly the contrib/hooks/update-paranoid script is a lot more
  powerful then gitosis is, in terms of how it controls what
  branches a user can modify, and even what files they can change
  on a particular branch.  And yes, I really do have rulesets that
  bend that hook to its limits.

* It uses the OpenSSH authorized_keys file format

  I'm required to use the F-Secure SSH commerical server at
  day-job, because its "more trusthworthy" than the portable OpenSSH
  distribution.  It uses a different syntax for the authorized keys,
  but can do essentially the same restricted command concept.

* If its in git, I prefer raw repository access

  gitosis yanks stuff out into normal files to access it at runtime,
  e.g. its configuration file.  I've had bad experiences with CVS not
  properly updating its admin files when changes are made to them.
  The update-paranoid hook I use actually cats the objects right
  out of the admin ODB on demand, ensuring its always evaluating
  the most recent version of the access rules.

* Its Python based.

  I don't grok Python, and would rather not learn to.  So hacking
  on gitosis isn't something that I would be doing.  Ditto with
  all of my day-job cohorts.  We use Perl, Bourne shell, and Java,
  with some tiny amount of Tk thrown about (though I'd say I'm
  probably the only one there that even remotely groks Tcl/Tk).

But thanks for the pointer.

Now if others corrected all of the above in gitosis (except the
last item of course, I don't expect it to be rewritten in one of
my preferred languages) I'd reconsider using it, because inventing
wheels sucks.

-- 
Shawn.

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

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-27 10:39 [RFC] Secure central repositories by UNIX socket authentication Shawn O. Pearce
2008-01-27 14:04 ` Johannes Schindelin
2008-01-27 17:32   ` Shawn O. Pearce
2008-01-27 18:51     ` Johannes Schindelin
2008-01-28  0:54       ` Shawn O. Pearce
2008-01-28  8:14     ` Dmitry Potapov
2008-01-27 22:56 ` Junio C Hamano
2008-01-28  0:16   ` git-daemon is insecure? (was: [RFC] Secure central repositories) Shawn O. Pearce
2008-01-28  3:00     ` git-daemon is insecure? Junio C Hamano
2008-01-28  3:20       ` Shawn O. Pearce
2008-01-28  0:47   ` [RFC] Secure central repositories by UNIX socket authentication Shawn O. Pearce
2008-01-28  7:25     ` Junio C Hamano
2008-01-28  7:51       ` Shawn O. Pearce
2008-01-28 14:23         ` Asheesh Laroia
2008-01-29  3:11           ` Shawn O. Pearce [this message]
2008-01-28  7:56       ` 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=20080129031105.GI24004@spearce.org \
    --to=spearce@spearce.org \
    --cc=asheesh@asheesh.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).