diff --git a/CHANGELOG b/CHANGELOG index b7d4330..91faaa5 100644 --- a/CHANGELOG +++ b/CHANGELOG @@ -1,18 +1,3 @@ -2012-12-29 v3.3 bug fix: gl-perms propagation to slaves broke sometime - after v3.2 (so if you're only picking up tagged releases - you're OK) - - the "D" command now allows rm/unlock to be totally - disabled - - new trigger: update-gitweb-daemon-from-options; another - way to update gitweb and daemon access lists - - new 'create' command for explicit wild repo creation, and - new AutoCreate trigger to control auto-creation - - allow simple macros in conf file - 2012-11-14 v3.2 major efficiency boost for large setups optional support for multi-line pubkeys; see diff --git a/README.md b/README.md deleted file mode 100644 index e650fa6..0000000 --- a/README.md +++ /dev/null @@ -1,359 +0,0 @@ -Github-users: click the 'wiki' link before sending me anything via github. - -Existing users: this is gitolite v3.x. If you are upgrading from v2.x this -file will not suffice; you *must* check the online docs (see below for URL). - ------------------------------------------------------------------------- - - -This file contains BASIC DOCUMENTATION ONLY. - -* It is suitable for a fresh, ssh-based, installation of gitolite and basic - usage of its most important features. -* It is NOT meant to be exhaustive or detailed. - -The COMPLETE DOCUMENTATION is at: - - http://sitaramc.github.com/gitolite/master-toc.html - -Please go there for what/why/how, concepts, background, troubleshooting, more -details on what is covered here, or advanced features not covered here. - ------------------------------------------------------------------------- - - -BASIC DOCUMENTATION FOR GITOLITE -================================ - -This file contains the following sections: - -* INSTALLATION AND SETUP -* ADDING USERS AND REPOS -* HELP FOR YOUR USERS -* BASIC SYNTAX -* ACCESS RULES -* GROUPS -* COMMANDS -* THE 'rc' FILE -* GIT-CONFIG -* GIT-DAEMON -* GITWEB -* CONTACT AND SUPPORT -* LICENSE - ------------------------------------------------------------------------- - - -INSTALLATION AND SETUP ----------------------- - -Server requirements: - -* any unix system -* sh -* git 1.6.6+ -* perl 5.8.8+ -* openssh 5.0+ -* a dedicated userid to host the repos (in this document, we assume it - is 'git'), with shell access ONLY by 'su - git' from some other userid - on the same server. - -Steps to install: - -* login as 'git' as described above -* make sure ~/.ssh/authorized_keys is empty or non-existent -* make sure your ssh public key from your workstation is available at $HOME/YourName.pub -* run the following commands: - - git clone git://github.com/sitaramc/gitolite - mkdir -p $HOME/bin - gitolite/install -to $HOME/bin - gitolite setup -pk YourName.pub - - If the last command doesn't run perhaps 'bin' in not in your 'PATH'. - You can either add it, or just run: - - $HOME/bin/gitolite setup -pk YourName.pub - - -ADDING USERS AND REPOS ----------------------- - -Do NOT add new repos or users manually on the server. Gitolite users, -repos, and access rules are maintained by making changes to a special repo -called 'gitolite-admin' and pushing those changes to the server. - ----- - -To administer your gitolite installation, start by doing this on your -workstation (if you have not already done so): - - git clone git@host:gitolite-admin - -**NOTE**: if you are asked for a password, something has gone wrong. - -Now if you 'cd gitolite-admin', you will see two subdirectories in it: -'conf' and 'keydir'. - -To add new users alice, bob, and carol, obtain their public keys and add -them to 'keydir' as alice.pub, bob.pub, and carol.pub respectively. - -To add a new repo 'foo' and give different levels of access to these -users, edit the file 'conf/gitolite.conf' and add lines like this: - - repo foo - RW+ = alice - RW = bob - R = carol - -See the 'ACCESS RULES' section later for more details. - -Once you have made these changes, do something like this: - - git add conf - git add keydir - git commit -m 'added foo, gave access to alice, bob, carol' - git push - -When the push completes, gitolite will add the new users to -~/.ssh/authorized_keys on the server, as well as create a new, empty, repo -called 'foo'. - - -HELP FOR YOUR USERS -------------------- - -Once a user has sent you their public key and you have added them as -specified above and given them access, you have to tell them what URL to -access their repos at. This is usually 'git clone git@host:reponame'; see -man git-clone for other forms. - -**NOTE**: again, if they are asked for a password, something is wrong. - -If they need to know what repos they have access to, they just have to run -'ssh git@host info'; see 'COMMANDS' section later for more on this. - - -BASIC SYNTAX ------------- - -The basic syntax of the conf file is very simple. - -* Everything is space separated; there are no commas, semicolons, etc., - in the syntax. -* Comments are in the usual perl/shell style. -* User and repo names are as simple as possible; they must start with an - alphanumeric, but after that they can also contain '.', '_', or '-'. - - Usernames can optionally be followed by an '@' and a domainname - containing at least one '.'; this allows you to use an email address - as someone's username. - - Reponames can contain '/' characters; this allows you to put your - repos in a tree-structure for convenience. -* There are no continuation lines. - - -ACCESS RULES ------------- - -This section is mostly 'by example'. - -Gitolite's access rules are very powerful. The simplest use was already -shown above. Here is a slightly more detailed example: - - repo foo - RW+ = alice - - master = bob - - refs/tags/v[0-9] = bob - RW = bob - RW refs/tags/v[0-9] = carol - R = dave - -For clones and fetches, as long as the user is listed with an R, RW -or RW+ in at least one rule, he is allowed to read the repo. - -For pushes, rules are processed in sequence until a rule is found -where the user, the permission (see note 1), and the refex (note 2) -*all* match. At that point, if the permission on the matched rule -was '-', the push is denied, otherwise it is allowed. If no rule -matches, the push is denied. - -Note 1: permission matching: - -* a permission of RW matches only a fast-forward push or create -* a permission of RW+ matches any type of push -* a permission of '-' matches any type of push - -Note 2: refex matching: -(refex = optional regex to match the ref being pushed) - -* an empty refex is treated as 'refs/.*' -* a refex that does not start with 'refs/' is prefixed with 'refs/heads/' -* finally, a '^' is prefixed -* the ref being pushed is matched against this resulting refex - -With all that background, here's what the example rules say: - -* alice can do anything to any branch or tag -- create, push, delete, rewind/overwrite etc. -* bob can create or fast-forward push any branch whose name does - not start with 'master' and create any tag whose name does not - start with 'v'+digit. -* carol can create tags whose names start with 'v'+digit. -* dave can clone/fetch. - - -GROUPS ------- - -Gitolite allows you to group users or repos for convenience. Here's an -example that creates two groups of users: - - @staff = alice bob carol - @interns = ashok - - repo secret - RW = @staff - - repo foss - RW+ = @staff - RW = @interns - -Group lists accumulate. The following two lines have the same effect as -the earlier definition of @staff above: - - @staff = alice bob - @staff = carol - -You can also use group names in other group names: - - @all-devs = @staff @interns - -Finally, @all is a special group name that is often convenient to use if -you really mean 'all repos' or 'all users'. - - -COMMANDS --------- - -Users can run certain commands remotely, using ssh. For example: - - ssh git@host help - -prints a list of available commands. - -The most commonly used command is 'info'. All commands respond to a -single argument of '-h' with suitable information. - -If you have shell on the server, you have a lot more commands available to -you; try running 'gitolite help'. - - -THE 'rc' FILE --------------- - -Some of the instructions below may require you to edit the rc file -(~/.gitolite.rc on the server). - -The rc file is perl code, but you do NOT need to know perl to edit it. -Just mind the commas, use single quotes unless you know what you're doing, -and make sure the brackets and braces stay matched up. - - -GIT-CONFIG ----------- - -Gitolite lets you set git-config values for individual repos without -having to log on to the server and run 'git config' commands: - - repo foo - config hooks.mailinglist = foo-commits@example.tld - config hooks.emailprefix = '[foo] ' - config foo.bar = '' - config foo.baz = - -**WARNING** - -The last syntax shown above is the *only* way to *delete* a config -variable once you have added it. Merely removing it from the conf -file will *not* delete it from the repo.git/config file. - -**SECURITY NOTE** - -Some git-config keys allow arbitrary code to be run on the server. - -If all of your gitolite admins already have shell access to the server -account hosting it, you can edit the rc file (~/.gitolite.rc) on the -server, and change the GIT_CONFIG_KEYS line to look like this: - - GIT_CONFIG_KEYS => '.*', - -Otherwise, give it a space-separated list of regular expressions that -define what git-config keys are allowed. For example, this one allows -only variables whose names start with 'gitweb' or with 'gc' to be -defined: - - GIT_CONFIG_KEYS => 'gitweb\..* gc\..*', - - -GIT-DAEMON ----------- - -Gitolite creates the 'git-daemon-export-ok' file for any repo that is -readable by a special user called 'daemon', like so: - - repo foo - R = daemon - - -GITWEB ------- - -Any repo that is readable by a special user called 'gitweb' will be added -to the projects.list file. - - repo foo - R = gitweb - -Or you can set one or more of the following config variables instead: - - repo foo - config gitweb.owner = some person's name - config gitweb.description = some description - config gitweb.category = some category - -**NOTE** - -You will probably need to change the UMASK in the rc file from the -default (0077) to 0027 and add whatever user your gitweb is running as -to the 'git' group. After that, you need to run a one-time 'chmod -R' -on the already created files and directories. - ------------------------------------------------------------------------- - - -CONTACT AND SUPPORT -------------------- - -Mailing list for support and general discussion: - gitolite@googlegroups.com - subscribe address: gitolite+subscribe@googlegroups.com - -Mailing list for announcements and notices: - subscribe address: gitolite-announce+subscribe@googlegroups.com - -IRC: #git and #gitolite on freenode. Note that I live in India (UTC+0530 -time zone). - -Author: sitaramc@gmail.com, but please DO NOT use this for general support -questions. Subscribe to the list and ask there instead. - - -LICENSE -------- - -The gitolite *code* is released under GPL v2. See COPYING for details. - -This documentation, which is part of the source code repository, is -provided under a Creative Commons Attribution-ShareAlike 3.0 Unported -License -- see http://creativecommons.org/licenses/by-sa/3.0/ diff --git a/README.txt b/README.txt new file mode 100644 index 0000000..08fed1c --- /dev/null +++ b/README.txt @@ -0,0 +1,373 @@ +Github-users: click the 'wiki' link before sending me anything via github. + +Existing users: this is gitolite v3.x. If you are upgrading from v2.x this +file will not suffice; you *must* check the online docs (see below for URL). + +------------------------------------------------------------------------ + + +This file contains BASIC DOCUMENTATION ONLY. + + * It is suitable for a fresh, ssh-based, installation of gitolite and basic + usage of its most important features. + + * It is NOT meant to be exhaustive or detailed. + +The COMPLETE DOCUMENTATION is at: + + http://sitaramc.github.com/gitolite/master-toc.html + +Please go there for what/why/how, concepts, background, troubleshooting, more +details on what is covered here, or advanced features not covered here. + +------------------------------------------------------------------------ + + +BASIC DOCUMENTATION FOR GITOLITE +================================ + +This file contains the following sections: + + INSTALLATION AND SETUP + ADDING USERS AND REPOS + HELP FOR YOUR USERS + BASIC SYNTAX + ACCESS RULES + GROUPS + COMMANDS + THE 'rc' FILE + GIT-CONFIG + GIT-DAEMON + GITWEB + + CONTACT AND SUPPORT + LICENSE + +------------------------------------------------------------------------ + + +INSTALLATION AND SETUP +---------------------- + + Server requirements: + + * any unix system + * sh + * git 1.6.6+ + * perl 5.8.8+ + * openssh 5.0+ + * a dedicated userid to host the repos (in this document, we assume it + is 'git'), with shell access ONLY by 'su - git' from some other userid + on the same server. + + Steps to install: + + * login as 'git' as described above + + * make sure ~/.ssh/authorized_keys is empty or non-existent + + * make sure your ssh public key from your workstation is available at + $HOME/YourName.pub + + * run the following commands: + + git clone git://github.com/sitaramc/gitolite + mkdir -p $HOME/bin + gitolite/install -to $HOME/bin + gitolite setup -pk YourName.pub + + If the last command doesn't run perhaps 'bin' in not in your 'PATH'. + You can either add it, or just run: + + $HOME/bin/gitolite setup -pk YourName.pub + + +ADDING USERS AND REPOS +---------------------- + + Do NOT add new repos or users manually on the server. Gitolite users, + repos, and access rules are maintained by making changes to a special repo + called 'gitolite-admin' and pushing those changes to the server. + + ---- + + To administer your gitolite installation, start by doing this on your + workstation (if you have not already done so): + + git clone git@host:gitolite-admin + + **NOTE**: if you are asked for a password, something has gone wrong. + + Now if you 'cd gitolite-admin', you will see two subdirectories in it: + 'conf' and 'keydir'. + + To add new users alice, bob, and carol, obtain their public keys and add + them to 'keydir' as alice.pub, bob.pub, and carol.pub respectively. + + To add a new repo 'foo' and give different levels of access to these + users, edit the file 'conf/gitolite.conf' and add lines like this: + + repo foo + RW+ = alice + RW = bob + R = carol + + See the 'ACCESS RULES' section later for more details. + + Once you have made these changes, do something like this: + + git add conf + git add keydir + git commit -m 'added foo, gave access to alice, bob, carol' + git push + + When the push completes, gitolite will add the new users to + ~/.ssh/authorized_keys on the server, as well as create a new, empty, repo + called 'foo'. + + +HELP FOR YOUR USERS +------------------- + + Once a user has sent you their public key and you have added them as + specified above and given them access, you have to tell them what URL to + access their repos at. This is usually 'git clone git@host:reponame'; see + man git-clone for other forms. + + **NOTE**: again, if they are asked for a password, something is wrong. + + If they need to know what repos they have access to, they just have to run + 'ssh git@host info'; see 'COMMANDS' section later for more on this. + + +BASIC SYNTAX +------------ + + The basic syntax of the conf file is very simple. + + * Everything is space separated; there are no commas, semicolons, etc., + in the syntax. + + * Comments are in the usual perl/shell style. + + * User and repo names are as simple as possible; they must start with an + alphanumeric, but after that they can also contain '.', '_', or '-'. + + Usernames can optionally be followed by an '@' and a domainname + containing at least one '.'; this allows you to use an email address + as someone's username. + + Reponames can contain '/' characters; this allows you to put your + repos in a tree-structure for convenience. + + * There are no continuation lines. + + +ACCESS RULES +------------ + + This section is mostly 'by example'. + + Gitolite's access rules are very powerful. The simplest use was already + shown above. Here is a slightly more detailed example: + + repo foo + RW+ = alice + - master = bob + - refs/tags/v[0-9] = bob + RW = bob + RW refs/tags/v[0-9] = carol + R = dave + + For clones and fetches, as long as the user is listed with an R, RW + or RW+ in at least one rule, he is allowed to read the repo. + + For pushes, rules are processed in sequence until a rule is found + where the user, the permission (see note 1), and the refex (note 2) + *all* match. At that point, if the permission on the matched rule + was '-', the push is denied, otherwise it is allowed. If no rule + matches, the push is denied. + + Note 1: permission matching: + + * a permission of RW matches only a fast-forward push or create + * a permission of RW+ matches any type of push + * a permission of '-' matches any type of push + + Note 2: refex matching: + (refex = optional regex to match the ref being pushed) + + * an empty refex is treated as 'refs/.*' + * a refex that does not start with 'refs/' is prefixed with 'refs/heads/' + * finally, a '^' is prefixed + * the ref being pushed is matched against this resulting refex + + With all that background, here's what the example rules say: + + * alice can do anything to any branch or tag -- create, push, + delete, rewind/overwrite etc. + + * bob can create or fast-forward push any branch whose name does + not start with 'master' and create any tag whose name does not + start with 'v'+digit. + + * carol can create tags whose names start with 'v'+digit. + + * dave can clone/fetch. + + +GROUPS +------ + + Gitolite allows you to group users or repos for convenience. Here's an + example that creates two groups of users: + + @staff = alice bob carol + @interns = ashok + + repo secret + RW = @staff + + repo foss + RW+ = @staff + RW = @interns + + Group lists accumulate. The following two lines have the same effect as + the earlier definition of @staff above: + + @staff = alice bob + @staff = carol + + You can also use group names in other group names: + + @all-devs = @staff @interns + + Finally, @all is a special group name that is often convenient to use if + you really mean 'all repos' or 'all users'. + + +COMMANDS +-------- + + Users can run certain commands remotely, using ssh. For example: + + ssh git@host help + + prints a list of available commands. + + The most commonly used command is 'info'. All commands respond to a + single argument of '-h' with suitable information. + + If you have shell on the server, you have a lot more commands available to + you; try running 'gitolite help'. + + +THE 'rc' FILE +-------------- + + Some of the instructions below may require you to edit the rc file + (~/.gitolite.rc on the server). + + The rc file is perl code, but you do NOT need to know perl to edit it. + Just mind the commas, use single quotes unless you know what you're doing, + and make sure the brackets and braces stay matched up. + + +GIT-CONFIG +---------- + + Gitolite lets you set git-config values for individual repos without + having to log on to the server and run 'git config' commands: + + repo foo + config hooks.mailinglist = foo-commits@example.tld + config hooks.emailprefix = '[foo] ' + config foo.bar = '' + config foo.baz = + + **WARNING** + + The last syntax shown above is the *only* way to *delete* a config + variable once you have added it. Merely removing it from the conf + file will *not* delete it from the repo.git/config file. + + **SECURITY NOTE** + + Some git-config keys allow arbitrary code to be run on the server. + + If all of your gitolite admins already have shell access to the server + account hosting it, you can edit the rc file (~/.gitolite.rc) on the + server, and change the GIT_CONFIG_KEYS line to look like this: + + GIT_CONFIG_KEYS => '.*', + + Otherwise, give it a space-separated list of regular expressions that + define what git-config keys are allowed. For example, this one allows + only variables whose names start with 'gitweb' or with 'gc' to be + defined: + + GIT_CONFIG_KEYS => 'gitweb\..* gc\..*', + + +GIT-DAEMON +---------- + + Gitolite creates the 'git-daemon-export-ok' file for any repo that is + readable by a special user called 'daemon', like so: + + repo foo + R = daemon + + +GITWEB +------ + + Any repo that is readable by a special user called 'gitweb' will be added + to the projects.list file. + + repo foo + R = gitweb + + Or you can set one or more of the following config variables instead: + + repo foo + config gitweb.owner = some person's name + config gitweb.description = some description + config gitweb.category = some category + + **NOTE** + + You will probably need to change the UMASK in the rc file from the + default (0077) to 0027 and add whatever user your gitweb is running as + to the 'git' group. After that, you need to run a one-time 'chmod -R' + on the already created files and directories. + + +------------------------------------------------------------------------ + + +CONTACT AND SUPPORT +------------------- + + Mailing list for support and general discussion: + gitolite@googlegroups.com + subscribe address: gitolite+subscribe@googlegroups.com + + Mailing list for announcements and notices: + subscribe address: gitolite-announce+subscribe@googlegroups.com + + IRC: #git and #gitolite on freenode. Note that I live in India (UTC+0530 + time zone). + + Author: sitaramc@gmail.com, but please DO NOT use this for general support + questions. Subscribe to the list and ask there instead. + + +LICENSE +------- + + The gitolite *code* is released under GPL v2. See COPYING for details. + + This documentation, which is part of the source code repository, is + provided under a Creative Commons Attribution-ShareAlike 3.0 Unported + License -- see http://creativecommons.org/licenses/by-sa/3.0/ diff --git a/src/commands/git-annex-shell b/src/commands/git-annex-shell new file mode 100755 index 0000000..a32ac20 --- /dev/null +++ b/src/commands/git-annex-shell @@ -0,0 +1,80 @@ +#!/usr/bin/perl + +use lib $ENV{GL_LIBDIR}; +use Gitolite::Easy; + +# This command requires unrestricted arguments, so instead of adding it to the +# COMMANDS hash in the usual way, you need to add it like so: +# 'git-annex-shell' => 'ua', +# (i.e., the value for the key should be the string 'ua'). +# +# This requires git-annex version 20111016 or newer. Older versions won't +# be secure. + +use strict; +use warnings; + +# ignore @ARGV and look at the original unmodified command +my $cmd = $ENV{SSH_ORIGINAL_COMMAND}; + +# Expect commands like: +# git-annex-shell 'configlist' '/~/repo' +# git-annex-shell 'sendkey' '/~/repo' 'key' +# The parameters are always single quoted, and the repo path is always +# the second parameter. +# Further parameters are not validated here (see below). +die "bad git-annex-shell command: $cmd" + unless $cmd =~ m#^(git-annex-shell '\w+' ')/\~/([0-9a-zA-Z][0-9a-zA-Z._\@/+-]*)('( .*|))$#; +my $start = $1; +my $repo = $2; +my $end = $3; +die "I dont like some of the characters in $repo\n" unless $repo =~ $Gitolite::Rc::REPONAME_PATT; +die "I dont like absolute paths in $cmd\n" if $repo =~ /^\//; +die "I dont like '..' paths in $cmd\n" if $repo =~ /\.\./; + +# Modify $cmd, fixing up the path to the repo to include GL_REPO_BASE. +my $newcmd = "$start$rc{GL_REPO_BASE}/$repo$end"; + +# Rather than keeping track of which git-annex-shell commands +# require write access and which are readonly, we tell it +# when readonly access is needed. +if ( can_write($repo) ) { +} elsif ( can_read($repo) ) { + $ENV{GIT_ANNEX_SHELL_READONLY} = 1; +} else { + die "$repo $ENV{GL_USER} DENIED\n"; +} +# Further limit git-annex-shell to safe commands (avoid it passing +# unknown commands on to git-shell) +$ENV{GIT_ANNEX_SHELL_LIMITED} = 1; + +# Note that $newcmd does *not* get evaluated by the unix shell. +# Instead it is passed as a single parameter to git-annex-shell for +# it to parse and handle the command. This is why we do not need to +# fully validate $cmd above. +Gitolite::Common::gl_log( $ENV{SSH_ORIGINAL_COMMAND} ); +exec "git-annex-shell", "-c", $newcmd; + +__END__ + +INSTRUCTIONS... (NEED TO BE VALIDATED BY SOMEONE WHO KNOWS GIT-ANNEX WELL). + +based on http://git-annex.branchable.com/tips/using_gitolite_with_git-annex/ +ONLY VARIATIONS FROM THAT PAGE ARE WRITTEN HERE. + +requirements: + + * gitolite v3.04+ (whatever version has src/commands/git-annex-shell, + because I haven't tagged it yet). + * git-annex as per that + +setup + + * in COMMANDS hash in the rc file, add an entry like this: + 'git-annex-shell' => 'ua', + (there is no GL_ADC_PATH and no "ua" subdirectory here, and nothing to + "install"; the command already comes with gitolite) + +That should be it; everything else should be as in that page. + +Once this is tested I'll move it to 'master'. diff --git a/src/commands/list-dangling-repos b/src/commands/list-dangling-repos index 6d86937..ea36bab 100755 --- a/src/commands/list-dangling-repos +++ b/src/commands/list-dangling-repos @@ -4,7 +4,6 @@ use warnings; use lib $ENV{GL_LIBDIR}; use Gitolite::Common; -use Gitolite::Conf::Load; =for usage Usage: gitolite list-dangling-repos @@ -41,9 +40,8 @@ for my $pr (keys %phy_repos) { # Remove regex matches. for my $pr (keys %phy_repos) { my $matched = 0; - my $pr2 = Gitolite::Conf::Load::generic_name($pr); for my $r (keys %repos) { - if ($pr =~ /^$r$/ or $pr2 =~ /^$r$/) { + if ($pr =~ /^$r$/) { $matched = 1; next; } diff --git a/src/commands/mirror b/src/commands/mirror index d72f9ae..d091979 100755 --- a/src/commands/mirror +++ b/src/commands/mirror @@ -48,7 +48,7 @@ if ( $cmd eq 'push' ) { if (-f "gl-creator") { # try to propagate the wild repo, including creator name and gl-perms my $creator = `cat gl-creator`; chomp($creator); - trace(1, `cat gl-perms 2>/dev/null | ssh $host CREATOR=$creator perms -c \\'$repo\\' 2>/dev/null`); + trace(1, `cat gl-perms 2>/dev/null | ssh $host CREATOR=$creator perms -c \\'$repo\\'`); } my $errors = 0; diff --git a/src/commands/perms b/src/commands/perms index 88244a9..6b61596 100755 --- a/src/commands/perms +++ b/src/commands/perms @@ -43,23 +43,23 @@ if ( $ARGV[0] eq '-l' ) { getperms(@ARGV); # doesn't return } -my $generic_error = "repo does not exist, or you are not authorised"; - # auto-create the repo if -c passed and repo doesn't exist if ( $ARGV[0] eq '-c' ) { shift; my $repo = $ARGV[0] or usage(); _die "invalid repo '$repo'" unless $repo =~ $REPONAME_PATT; - if (not -d "$rc{GL_REPO_BASE}/$repo.git") { - my $ret = access( $repo, $ENV{GL_USER}, '^C', 'any' ); - _die $generic_error if $ret =~ /DENIED/; + my $d = "$rc{GL_REPO_BASE}/$repo.git"; + my $errmsg = "repo already exists or you are not authorised to create it"; + # use the same message in both places to prevent leaking repo existence info + _die $errmsg if -d $d; + my $ret = access( $repo, $ENV{GL_USER}, '^C', 'any' ); + _die $errmsg if $ret =~ /DENIED/; - require Gitolite::Conf::Store; - Gitolite::Conf::Store->import; - new_wild_repo( $repo, $ENV{GL_USER}, 'perms-c' ); - gl_log( 'create', $repo, $ENV{GL_USER}, 'perms-c' ); - } + require Gitolite::Conf::Store; + Gitolite::Conf::Store->import; + new_wild_repo( $repo, $ENV{GL_USER}, 'perms-c' ); + gl_log( 'create', $repo, $ENV{GL_USER}, 'perms-c' ); } my $repo = shift; @@ -70,7 +70,7 @@ _system( "gitolite", "trigger", "POST_CREATE", $repo, $ENV{GL_USER}, 'perms' ); sub getperms { my $repo = shift; - _die $generic_error if repo_missing($repo) or creator($repo) ne $ENV{GL_USER}; + _die "sorry you are not authorised" if repo_missing($repo) or creator($repo) ne $ENV{GL_USER}; my $pf = "$rc{GL_REPO_BASE}/$repo.git/gl-perms"; print slurp($pf) if -f $pf; @@ -79,20 +79,17 @@ sub getperms { } sub setperms { - _die $generic_error if repo_missing($repo) or creator($repo) ne $ENV{GL_USER}; + _die "sorry you are not authorised" if repo_missing($repo) or creator($repo) ne $ENV{GL_USER}; my $pf = "$rc{GL_REPO_BASE}/$repo.git/gl-perms"; if ( not @_ ) { # legacy mode; pipe data in - print STDERR "'batch' mode started, waiting for input (run with '-h' for details).\n"; - print STDERR "Please hit Ctrl-C if you did not intend to do this.\n"; @ARGV = (); my @a; for (<>) { _die "Invalid role '$1'; check the rc file" if /(\S+)/ and not $rc{ROLES}{$1}; push @a, $_; } - print STDERR "\n"; # make sure Ctrl-C gets caught _print( $pf, @a ); return; } diff --git a/src/gitolite-shell b/src/gitolite-shell index a3ec321..8f3a128 100755 --- a/src/gitolite-shell +++ b/src/gitolite-shell @@ -152,10 +152,11 @@ sub parse_soc { # after this we should not return; caller expects us to handle it all here # and exit out - _die "suspicious characters loitering about '$soc'" if $soc !~ $REMOTE_COMMAND_PATT; my @words = split ' ', $soc; if ( $rc{COMMANDS}{ $words[0] } ) { + _die "suspicious characters loitering about '$soc'" + if $rc{COMMANDS}{ $words[0] } ne 'ua' and $soc !~ $REMOTE_COMMAND_PATT; trace( 2, "gitolite command", $soc ); _system( "gitolite", @words ); exit 0; diff --git a/src/lib/Gitolite/Conf/Load.pm b/src/lib/Gitolite/Conf/Load.pm index 6c133e2..2611630 100644 --- a/src/lib/Gitolite/Conf/Load.pm +++ b/src/lib/Gitolite/Conf/Load.pm @@ -246,7 +246,7 @@ sub load_1 { } if ( -f "gl-conf" ) { - return if not $split_conf{$repo}; + _warn "split conf not set, gl-conf present for '$repo'" if not $split_conf{$repo}; my $cc = "./gl-conf"; _die "parse '$cc' failed: " . ( $! or $@ ) unless do $cc; @@ -386,8 +386,6 @@ sub user_roles { for (@roles) { # READERS u3 u4 @g1 s/^\s+//; s/ +$//; s/=/ /; s/\s+/ /g; s/^\@//; - next if /^#/; - next unless /\S/; my ( $role, @members ) = split; # role = READERS, members = u3, u4, @g1 if ( $role ne 'CREATOR' and not $rc{ROLES}{$role} ) { diff --git a/t/sequence.t b/t/sequence.t index 87f3731..a42b6b6 100755 --- a/t/sequence.t +++ b/t/sequence.t @@ -100,7 +100,7 @@ try " # auto-create using perms fail echo READERS u5 | glt perms u4 -c foo/u4/baz !/Initialized empty Git repository in .*/foo/u4/baz.git/ - /FATAL: repo does not exist, or you are not authorised/ + /FATAL: repo already exists or you are not authorised to create it/ # auto-create using perms echo READERS u2 | glt perms u1 -c foo/u1/baz