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