deac/gitolite
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity
Hosting git repositories -- Gitolite allows you to setup git hosting on a central server, with very fine-grained access control and many (many!) more powerful features.
699 commits 6 branches 50 tags 2.8 MiB
Perl 88.8%
Shell 10.3%
Public Key 0.8%
Raku 0.1%
Find a file
Sitaram Chamarty 817c1835ae (docfix) you need RW+ to overwrite a tag 
to my eternal shame (considering how proud I am of my documentation)
this was not mentioned anywhere!  I'm getting old...

thanks to Pierre Habouzit for catching this

(also slipped in a few other minor doc changes.  I wouldn't mix
unrelated stuff in a commit when doing code changes but it seems ok to
do this for docfixes, for some reason).
2011-08-01 08:12:23 +05:30
conf Make limit on number of repos displayed by info with GL_BIG_CONFIG configurable 2011-03-30 20:27:12 +05:30
contrib (minor) fixed some broken links due to 867b34f 2011-07-18 21:06:14 +05:30
doc (docfix) you need RW+ to overwrite a tag 2011-08-01 08:12:23 +05:30
hooks die() needs to be defined in post-update hook 2011-06-19 06:54:52 +05:30
src (minor) don't ignore dirty-ness when generating version number 2011-07-29 14:12:56 +05:30
t make gl-system-install easier to run 2011-05-28 18:14:19 +05:30
.gitattributes docs and .gitattributes hadn't been updated for the change in hooks dir 2010-03-10 06:24:53 +05:30
.gitignore add conf/VERSION to .gitignore 2010-03-02 05:39:19 +05:30
Makefile Makefile: now default is as simple as "make" 2010-05-14 11:27:55 +05:30
README.mkd (docfix) you need RW+ to overwrite a tag 2011-08-01 08:12:23 +05:30

README.mkd

Hosting git repositories

Gitolite allows you to setup git hosting on a central server, with fine-grained access control and many (many!) more powerful features.

Impatient? The install document has a quick install section at the top. Just remember that "impatient" does not always mean "successful" ;-)

Gitolite is an access control layer on top of git, which allows access control down to the branch level, including specifying who can and cannot rewind a given branch. Here's some information on some of the projects and people using gitolite (and who, in turn, have helped shape its features).

Gitolite comes with a huge amount of documentation. If you're absolutely new, the suggested reading order is this:

There is also a master TOC of all gitolite documentation; use your browser's search function (Ctrl-F, usually) to look for likely sounding words or just browse around -- you never know what you'll find!

In this document:

what

Gitolite lets you use a single user on a server to host many git repositories and provide access to many developers, without having to give them real userids on or shell access to the server. Authentication is most commonly done using sshd, but you can also use httpd if you prefer.

Gitolite can restrict who can read from (clone/fetch) or write to (push) a repository. It can also restrict who can push to what branch or tag, which is very important in a corporate environment. Gitolite can be installed without requiring root permissions, and with no additional software than git itself and perl. It also has several other neat features described below and elsewhere in the doc/ directory.

why

Gitolite is separate from git, and needs to be installed and configured. So... why do we bother?

Gitolite is useful in any server that is going to host multiple git repositories, each with many developers, where some sort of access control is required.

In theory, this can be done with plain old Unix permissions: each user is a member of one or more groups, each group "owns" one or more repositories, and using unix permissions (especially the setgid bit -- chmod g+s) you can allow/disallow users access to repos.

But there are several disadvantages here:

  • every user needs a userid and password on the server. This is usually a killer, especially in tightly controlled environments
  • adding/removing access rights involves complex usermod -G ... mumblings which most admins would rather not deal with
  • viewing (aka auditing) the current set of permissions requires running multiple commands to list directories and their permissions/ownerships, users and their group memberships, and then correlating all these manually
  • auditing historical permissions or permission changes is pretty much impossible without extraneous tools
  • errors or omissions in setting the permissions exactly can cause problems of either kind: false accepts or false rejects
  • without going into ACLs it is not possible to give some people read-only access while some others have read-write access to a repo (unless you make it world-readable). Group access just doesn't have enough granularity
  • it is absolutely impossible to restrict pushing by branch name or tag name.

Gitolite does away with all this:

  • it uses ssh magic to remove the need to give actual unix userids to developers
  • it uses a simple but powerful config file format to specify access rights
  • access control changes are affected by modifying this file, adding or removing user's public keys, and "compiling" the configuration
  • this also makes auditing trivial -- all the data is in one place, and changes to the configuration are also logged, so you can audit them.
  • finally, the config file allows distinguishing between read-only and read-write access, not only at the repository level, but at the branch level within repositories.

main features

The most important feature I needed was per-branch permissions. This is pretty much mandatory in a corporate environment, and is almost the single reason I started thinking about writing gitolite.

It's not just "read-only" versus "read-write". Rewinding a branch (aka "non fast forward push") is potentially dangerous, but sometimes needed. So is deleting a branch (which is really just an extreme form of rewind). I needed something in between allowing anyone to do it (the default) and disabling it completely (receive.denyNonFastForwards or receive.denyDeletes).

Here're some more features. All of them, and more, are documented in detail somewhere in gitolite's doc/ subdirectory.

  • simple, yet powerful, config file syntax, including specifying gitweb/daemon access. You'll need this power if you manage lots of users+repos+combinations of access
  • apart from branch-name based restrictions, you can also restrict by file/dir name changed (i.e., output of git diff --name-only)
  • if your requirements are still too complex, you can split up the config file and delegate authority over parts of it
  • easy to specify gitweb owner, description and gitweb/daemon access
  • easy to sync gitweb (http) authorisation with gitolite's access config
  • comprehensive logging [aka: management does not think "blame" is just a synonym for "annotate" :-)]
  • "personal namespace" prefix for each dev
  • migration guide and simple converter for gitosis conf file
  • "exclude" (or "deny") rights at the branch/tag level
  • specify repos using patterns (patterns may include creator's name)
  • define powerful operations on the server side, even github-like forking

security

Due to the environment in which this was created and the need it fills, I consider this a "security" program, albeit a very modest one.

For the first person to find a security hole in it, defined as allowing a normal user (not the gitolite admin) to read a repo, or write/rewind a ref, that the config file says he shouldn't, and caused by a bug in code that is in the "master" branch, (not in the other branches, or the configuration file or in Unix, perl, shell, etc.)... well I can't afford 1000 USD rewards like djb, so you'll have to settle for 5000 INR (Indian Rupees) as a "token" prize :-)

However, there are a few optional features (which must be explicitly enabled in the RC file) where I just haven't had the time to reason about security thoroughly enough. Please read the comments in conf/example.gitolite.rc for details, looking for the word "security".

contact and license

Gitolite is released under GPL v2. See COPYING for details.