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

Re: Git and securing a repository

From
Shawn O. Pearce <spearce@spearce.org>
Date
Jan 3, 2008, 03:58 UTC
Message-ID
<20080103035838.GA24004@spearce.org>
In-Reply-To
<m3ir2co5s4.fsf@roke.D-201>
Jakub Narebski <jnareb@gmail.com> wrote:
Show 9 quoted lines
> Gonzalo Garramuño <ggarra@advancedsl.com.ar> writes:
> > David Symonds wrote:
> >>
> >> You can do arbitrarily-fine-grained authentication via the
> >> pre-receive hook.
> > 
> > Can you provide some more info?  Looking at the kernel.org git docs,
> > the pre-receive hook seems very limited as no parameters are allowed.
> > So I'm not sure how an authentication system could be created.

If you read the documentation carefully you will note that the pre-receive hook receives input on stdin; 1 line of data per ref that is being pushed with the old/new SHA-1 values and the ref name. The hook exits 0 to allow all changes to take place and can exit > 0 to abort and disallow all updates.

This is a "batch" form of the update hook.
Show 5 quoted lines
> > It also seems to be a push hook only (not invoked on pulls).
> 
> Some of read-only (fetch only) access protocols do not support
> authentication: http, ftp, rsync, git. Authentication is provided only
> for access via ssh and for push via https (WebDAV).
Authentication could be supported for http, ftp, or ssh based fetch,
but there you are relying on the server that provides access to do
the authentication and authorization for you; typically that will
boil down to UNIX filesystem read permission.  Though with HTTP
and a fancy Apache config it doesn't have to be.
 
> There is example update hook in contrib/hooks, named update-paranoid,
> which could be base of what you want. Note that you probably rather
> use newer pre-receive hook instead of older update hook.

update-paranoid uses the update hook rather than pre-receive to allow it to allow/deny on a per-ref basis. One of the flaws of the pre-receive hook "API" is it is an all-or-nothing proposition.

So by using the "older" update hook update-paranoid can make its
decision on a per-ref basis and allow some refs to change in this
push but abort/deny others.  I find that useful but not everyone
might.
 
> AFAIK both update and pre-receive hooks are invoked also on fetch...
> but I might be mistaken.

No, they are *not* invoked on fetch. Currently no hooks execute during fetch; either on the server *or* on the client side of the connection.

-- 
Shawn.
Previous: Jakub NarebskiNext: Bruno Cesar Ribas
Message 7 of 18 in “Git and securing a repository”
  1. Gonzalo GarramuñoJan 2, 2008
  2. Felipe BalbiJan 2, 2008
  3. Gonzalo GarramuñoJan 2, 2008
  4. David SymondsJan 2, 2008
  5. Gonzalo GarramuñoJan 2, 2008
  6. Jakub NarebskiJan 2, 2008
  7. Shawn O. PearceJan 3, 2008
  8. Bruno Cesar RibasJan 3, 2008
  9. Gonzalo GarramuñoJan 3, 2008
  10. Shawn O. PearceJan 3, 2008
  11. Gonzalo GarramuñoJan 3, 2008
  12. Shawn O. PearceJan 3, 2008
  13. Jakub NarebskiJan 3, 2008
  14. Junio C HamanoJan 3, 2008
  15. Jan HudecJan 2, 2008
  16. Gregory JefferisJan 2, 2008
  17. Linus TorvaldsJan 2, 2008
  18. Daniel BarkalowJan 2, 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.