git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC] Secure central repositories by UNIX socket authentication

From
Shawn O. Pearce <spearce@spearce.org>
Date
Jan 29, 2008, 03:11 UTC
Message-ID
<20080129031105.GI24004@spearce.org>
In-Reply-To
<alpine.DEB.1.00.0801280922160.3774@alchemy.localdomain>
Asheesh Laroia <asheesh@asheesh.org> wrote:
Show 10 quoted lines
> 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.
Previous: Asheesh LaroiaNext: Shawn O. Pearce
Message 15 of 16 in “[RFC] Secure central repositories by UNIX socket authentication”
  1. Shawn O. PearceJan 27, 2008
  2. Johannes SchindelinJan 27, 2008
  3. Shawn O. PearceJan 27, 2008
  4. Johannes SchindelinJan 27, 2008
  5. Shawn O. PearceJan 28, 2008
  6. Dmitry PotapovJan 28, 2008
  7. Junio C HamanoJan 27, 2008
  8. git-daemon is insecure? (was: [RFC] Secure central repositories)Shawn O. Pearce, Jan 28, 2008
  9. Junio C HamanoJan 28, 2008
  10. Shawn O. PearceJan 28, 2008
  11. Shawn O. PearceJan 28, 2008
  12. Junio C HamanoJan 28, 2008
  13. Shawn O. PearceJan 28, 2008
  14. Asheesh LaroiaJan 28, 2008
  15. Shawn O. PearceJan 29, 2008
  16. Shawn O. PearceJan 28, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.