Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Apr 13, 2010
Commits on Apr 10, 2010
Commits on Apr 9, 2010
  1. new server-side program "gl-tool", subcommand "shell-add"

    Previous implementations of "give shell access to some gitolite users"
    feature were crap.  There was no easy/elegant way to ensure that someone
    who had repo admin access would not manage to get himself shell access.
    Giving someone shell access requires that you should have shell access
    in the first place, so the simplest way is to enable it from the server
    side only.
    So now that we decided to do that, we may as well prepare for other,
    future, commands by starting a server-side utility program with
    sub-commands (the only current one being "shell-add")
  2. security: gitolite admin can get shell access by using screwy pubkey …

    example: keydir/sitaram@$(some-dangerous-command; echo hi).pub
    (still won't get the reward; that is only if a non-admin user gets
Commits on Mar 31, 2010
Commits on Mar 30, 2010
  1. compile/update: new "D" permission

    normally, RW+ means permission to rewind or delete.
    Now, if you use "D" permission anywhere in a repo config, that means
    "delete" and RW+ then means only "rewind", no delete.
Commits on Mar 29, 2010
  1. auth, do not leak info about repo existence

    All this is about a user trying to look if a repo exists or not, when he
    does not have any access to that repo.  Ideally, "repo does not exist"
    should be indistinguishable from "you dont have perms to that repo".
    (1) if $GL_WILDREPOS is not set, you either get a permissions error, or
        a "$repo not found in compiled config" death.  Fixed.
    (2) if $GL_WILDREPOS is set, you either get either a permissions error,
        or a "$repo has no matches" death.  Fixed.
    (3) The following combination leaks info about repo existence:
          - actual repo doesn't exist
          - spying user don't have C perms
          - repo patt doesn't contain CREATER
          - RW+ = CREATER is specified (as is normal)
        In such case, the "convenience copy" of the ACL that parse_acl
        makes, coupled with substituting CREATER for the invoking user means
        $repos{$actual_repo} has RW+ for the spying user.  This means the
        access denied doesn't happen, and control passes to git, which
        promptly expresses it unhappiness and angst over being given a repo
        that 'does not appear to be a git repository'
        This doesn't happen if all those conditions are not met:
          - if repo exists, CREATER is set to the real creater, so RW+ =
            CREATER does not gain spying user anything
          - if spying user has C perms it just gets created, because he has
            rights.  This is also info leak but we can't prevent it; tighten
            the config (maybe by including CREATER in repo pattern) if this
            is not wanted
          - if repo patt contains CREATER it will never match someone else's
            repo anyway!
Commits on Mar 27, 2010
  1. auth: do not implicitly assign RW access for creaters

    a configuration like this:
        repo CREATER/.*
            C       =   CREATER
            RW+     =   WRITERS
    was buggy; CREATER was implicitly part of WRITERS so he got RW
    permissions implicitly, so the push went through
Commits on Mar 26, 2010
  1. silly little PATH bug...

    what this means is that until now, everyone who used easy-install
    (without needing to set $GIT_PATH in the rc file) had a client-side PATH
    that was perfectly valid on the server side also!
  2. @all for repos is now much cleaner; a true @all...

      - no need to put it at the end of the config file now, yeaaay!
      - @all for @all is meaningless and not supported.  People asking will
        be told to get a life or use git-daemon.
      - NAME/ limits for @all repos is ignored for efficiency reasons.
Commits on Mar 23, 2010
Commits on Mar 18, 2010
  1. gl-setup: dash-compat

    before someone runs it on the new Ubuntu :)
Commits on Mar 17, 2010
  1. compile: remove the sortsub for data dumper

    Data dumper was failing (returning an empty string!) on an input config
    file of about 350 lines or so (output 2400 lines or so).
    Removing the sort sub fixed the problem.
    To recap why that sub was put in (see deleted lines in this commit for
    details), what we really want is that $creater must appear *last* in the
    resulting dump.
    So we trick it.  "man ascii" tells you that ~ is the highest valued
    ASCII character (yes, I know, not utf-8 safe etc... I'll deal with that
    if and when needed or punt!).  So we just put that in front of $creater
    and remove it later...
    You *don't* want to do this for $readers and $writers -- then they will
    once again sort *after* $creater, which would be a bad thing.  Also,
    it's probably better this way, because now the order of the hash keys
    will be: $readers, $writers, any actual users listed, and then $creater.
    This means the effective access rights will be:
    1.  if you are the creater you get CREATER's rights
    2.  else if your userid is listed *explicitly* in the config, you get
        those rights
    3.  else if you've been setperm'd as a writer, you get WRITERS rights
    4.  else if you've been setperm'd as a reader, you get READERS rights
    This is different from what used to happen till now; READERS and WRITERS
    used to trump explicitly given rights.  I'd been meaning to fix that
    somehow, but never got around to it, until this DDD (damn Data Dumper!)
    forced my hand :)
Commits on Mar 16, 2010
  1. compile/update hook: enable new style personal branches

    The new style personal branches work by interpreting the special
    sequence /USER/ (including the slashes) in a refname.  Docs should be in
    the next commit...
Commits on Mar 14, 2010
  1. update hook now allows chaining to "update.secondary"

    the changes to cp/scp are because without "-p" they dont carry perms
    across to existing files.  So if you forgot to chmod +x your custom
    hook and ran easy install, then after that you have to go to the server
    side to fix the perms...
Commits on Mar 12, 2010
  1. minor LFCR -> CRLF fix

  2. dps: gl-setup may have to create ~/.ssh and touch the authkeys file...

    I've been unwilling to create the authkeys file if it does not already
    exist, because it represents a significant change in accessibility for
    that account.
    However, in the "distro package" scenario, one wants to make it as easy
    as possible for the end-user (who is actually an admin for the gitolite
    being hosted on his account, let's not forget) to use.
    And it seems that in some cases that might mean he does not (yet) have a
    ~/.ssh even...
Commits on Mar 9, 2010
  1. easy install: suppress that misleading "fatal"

    get rid of the "fatal: No HEAD commit to compare with (yet)" message
  2. easy install seemed to out of the GIT_PATH loop

    for some reason, I apparently did not test easy install with a
    non-standard path!  Fixed...
Commits on Mar 7, 2010
  1. compile: make it easier to move repos into gitolite

    when repos are copied over from elsewhere, one had to run easy install
    once again to make the new (OS-copied) repo contain the proper update
    We eliminate this step now, using a new, empty, "hook" as a sentinel and
    having "compile" check/fix all repos' hooks.
    Since you have to add the repos to conf anyway, this makes it as
    seamless as possible.  The correct sequence now is
      - (server) copy the repo at the OS level
      - (admin clone) add it to conf/gitolite.conf, commit, push
Commits on Mar 1, 2010
Commits on Feb 27, 2010
  1. @tmatilai

    auth: do not anchor the pattern given for expand

    tmatilai authored committed
    Currently the pattern of expand command is line anchored.  This is
    different than in e.g. grep, and causes extra work to add '.*' prefix
    and/or suffix in many use cases.
    The new semantics now mean you might get more matches than you would
    have gotten earlier.  However, the expand command is still totally
    undocumented, so I think it is acceptable to change the functionality.
    This patch removes the anchoring.  So for earlier behavior the specified
    pattern needs be in form of '^<pattern>$'.  The default pattern is also
    changed from '.*' to '^', so there might be even a small speed
    improvement. =)
    Signed-off-by: Teemu Matilainen <>
Commits on Feb 26, 2010
  1. Merge branch 'master' into pu (damn!)

    stupid me; committed the easy install patch on master *and* pushed,
    instead of on pu...
    Since I dont want to rewind master, we end up with this completely
    unnecessary merge.
Commits on Feb 25, 2010
  1. Merge branch 'dps' into master

Commits on Feb 18, 2010
  1. auth: behave better when no argument supplied to wild commands

    expand gets a default '.*' argument
    others die with an error message
  2. @tmatilai

    List also non-wildcard repos in expand_wild

    tmatilai authored
    List also all matching and accessible non-wildcard repositories
    in ssh expand command.
    Signed-off-by: Teemu Matilainen <>
  3. compile: move checking of reponame/repopatt/username out of expand_list

    let expand_list be just that "expand a list", and leave checking to be
    done outside.
    otherwise, commit 690604d has the side effect of restricting refs to
    $REPOPATT_PATT, and so for instance barfing on the perfectly valid
        RW+ refs/(?!heads/master) = alice bob
    (thanks to Teemu for catching this)
Commits on Feb 14, 2010
  1. htpassword: disallow empty passwords

    Sitaram Chamarty authored
    [TODO: allow a callback for a password checking function, such as
    "passwd_policy_check".  Question is where the function would go.
    ~/.gitolite.rc is the only possible place among the current set of files
    but I'd rather leave that as a list of simple name=value lines for all
    sorts of reasons.  So maybe something like ~/ (analogous to
    the "" in the sources I supply), which would get "require'd"
    if found, and would contain all user-defined functions like this one...
    needs some thinking about]
Commits on Feb 13, 2010
  1. compile: users and repos have groups... why not refs?

    Sitaram Chamarty authored
    this came up in some other discussion with bremner.  As usual I said no
    I won't do it because I don't see any real need.
    ...then I realised it's just one line :)
Something went wrong with that request. Please try again.