aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* | Merge branch 'master' into pu-wildreposSitaram Chamarty2010-02-011-4/+6
|\|
| * Merge remote branch 'origin/pu'v1.0rc1v1.0Sitaram Chamarty2010-02-0113-146/+658
| |\
| | * doc/3: couple of clarificationsSitaram Chamarty2010-01-301-3/+5
| | | | | | | | | | | | | | | - deny rules only apply to "W" ops - be more specific about what allows "R" to pass
| * | doc/3: gitweb integ; trailing slash on $projectrootSitaram Chamarty2010-01-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | It's not clear whether $projectroot has or does not have a trailing slash. Current code assumes it does, but we need to cater for it not having one also. Otherwise the final reponame ends up with a leading slash, once $projectroot has been stripped from the beginning of the full repo path.
* | | auth: minor fix to reporting on wildcard reposSitaram Chamarty2010-01-301-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mpenz asked what would happen if the config looked like repo foo/abc R sitaram repo foo/.* RW sitaram If you asked for an expand of '.*', it would pick up permissions from the second set (i.e., "RW") and print them against "foo/abc". This is misleading, since those are not the permissions that will actually be *used*. Gitolite always uses the more specific form if it is given, which means your actual permissions are just "R". This patch is to prevent that misleading reporting in this corner case.
* | | auth: reporting changes for wildcard-created reposSitaram Chamarty2010-01-292-4/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - see *all* wildcard repos you have access to (this uses line-anchored regexes as described in doc/4). Examples: ssh git@server expand '.*' ssh git@server expand 'assignment.*' - show perms like the info command does Please see comments against 02cee1d for more details and caveats.
* | | Merge branch 'pu' into pu-wildreposSitaram Chamarty2010-01-296-87/+309
|\ \ \ | | |/ | |/|
| * | easy install: two rc file update bugs fixedSitaram Chamarty2010-01-271-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "msysgit doesnt have 'comm'" commit (from 2 days ago), had 2 bugs: - (smaller) the "+++" which was part of the diff header was triggering a spurious rc file "new variables" warning, but there were no actual variables to update - (bigger) worse, the grep command, when there were no matches, coupled with the "set -e" to kill the program right there (ouch!)
| * | document the "include" mechanismSitaram Chamarty2010-01-272-0/+18
| | |
| * | (rats! msysgit doesnt have 'comm'...)Sitaram Chamarty2010-01-251-3/+6
| | |
| * | sshkeys-lint: new programSitaram Chamarty2010-01-252-0/+104
| | | | | | | | | | | | run without arguments for usage
| * | doc/6 revamp: minor additionSitaram Chamarty2010-01-251-1/+10
| | |
| * | compile: allow "#" in *simple* stringsSitaram Chamarty2010-01-231-2/+2
| | | | | | | | | | | | | | | | | | like: config notify.ircChannel = "#foo" (thanks, jhelwig)
| * | doc/6 revamp; would appreciate reviews ;-)Sitaram Chamarty2010-01-222-82/+168
| | |
* | | "expand" should print to SDTOUT instead of STDERRTeemu Matilainen2010-01-281-1/+1
| | | | | | | | | | | | | | | | | | | | | Other ssh commands where fixed in 15475f666c07e66d91fd00added2a50544d9221b, but "expand" was somehow missed. Signed-off-by: Teemu Matilainen <teemu.matilainen@reaktor.fi>
* | | Merge branch 'master' into wildreposSitaram Chamarty2010-01-172-3/+11
|\| | | | | | | | | | | | | | | | | major changes brought in: compile: disallow multiple pubkeys in one file
| * | compile: disallow multiple pubkeys in one fileSitaram Chamarty2010-01-171-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way pubkey files are handled by gitolite, this could be used by a repo admin to get shell access. It's always been there as an undocumented emergency mechanism for an admin who lost his shell keys or overwrote them due to not understanding ssh well enough (and it has been so used at least once). But not any more... Like the @SHELL case, this reflects a shift away from treating people with repo admin rights as eqvt to people who have shell on the server, and systematically making the former lesser privileged than the latter. While in most cases (including my $DAYJOB) these two may be the same person, I am told that's not a valid assumption for others, and there've been requests to close this potential loophole.
| * | mention NAME-based restrictions in READMESitaram Chamarty2010-01-151-0/+2
| | |
| * | delegation doc: minor oopsSitaram Chamarty2010-01-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I know hardly anyone is using delegation, but if you find yourself locked out from pushing because of this one little thing, do this: * on your gitolite-admin clone, add the required lines per this patch, and commit * on the server, edit ~/.gitolite/conf/gitolite.conf-compiled.pm, and delete the following line 'NAME_LIMITS' => 1 from the entry for "gitolite-admin" (if you don't know what that means delete *all* such lines) and save the file * back on your admin repo clone, do a push
* | | delegation doc: minor oopsSitaram Chamarty2010-01-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I know hardly anyone is using delegation, but if you find yourself locked out from pushing because of this one little thing, do this: * on your gitolite-admin clone, add the required lines per this patch, and commit * on the server, edit ~/.gitolite/conf/gitolite.conf-compiled.pm, and delete the following line 'NAME_LIMITS' => 1 from the entry for "gitolite-admin" (if you don't know what that means delete *all* such lines) and save the file * back on your admin repo clone, do a push
* | | Merge branch 'master' into wildreposSitaram Chamarty2010-01-1411-81/+359
|\| | | | | | | | | | | | | | Conflicts: src/hooks/update
| * | @SHELL is now $SHELL_USERS in the rc file (warning: backward compat breakage)Sitaram Chamarty2010-01-145-28/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | Stop conflating the privilege to push changes to the admin repo with the privilege to get a shell on the server. Please read doc/6 carefully before upgrading to this version. Also please ensure that the gitolite key is *not* your only means to get a command line on the server
| * | update hook: anchor refex with ^ when matching refsSitaram Chamarty2010-01-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, a line like RW foo = user1 allows user1 to push any ref that contains the string refs/heads/foo. This includes refs like refs/heads/foo refs/heads/foobar refs/heads/foo/bar which is fine; that is what is intended. (You can always use foo$ instead of foo if you want to prevent the latter two). Similarly, RW refs/foo = user1 allows refs/foo refs/foobar refs/foo/bar Now, I don't see this as a "security risk" but the fact is that this allows someone to clutter your repo with junk like refs/bar/refs/heads/foo refs/heads/bar/refs/heads/foo (or, with the second config line example, refs/bar/refs/foo refs/heads/bar/refs/foo ) My personal advice is if you find someone doing that intentionally, you should probably take him out and shoot him [*], but since now *two* people have complained about this, here goes... ---- [*] you don't have to take him out if you don't want to
| * | compile: support "include" definitionTeemu Matilainen2010-01-101-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Support config file including using: include "filename" If filename is not an absolute path, it is looked from the $GL_ADMINDIR/conf/ directory. For security reasons include is not allowed for fragments. Signed-off-by: Teemu Matilainen <teemu.matilainen@reaktor.fi>
| * | change delegation to NAME/ style (warning: backward compat breakage)Sitaram Chamarty2010-01-102-40/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a backward incompatible change. If you are using delegation and you upgrade to this version, please do the following: * change your gitolite.conf file to use the new syntax (see doc/5-delegation.mkd in this commit) * for each branch "foo" in the gitolite-admin repo, do this: # (on "master" branch) git checkout foo -- conf/fragments/foo.conf * git add all those new fragments and commit to master * delete all the branches on your clone and the server # again, for each branch foo git branch -D foo git push origin :foo
| * | deprecation warning about old style PATH/ syntaxSitaram Chamarty2010-01-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (this commit will probably get reverted after a suitable period has elapsed and no one is likely to still be using the old syntax). Forgetting to change it to NAME/ after is a security issue -- you end up permitting stuff you don't want to! This commit allows the old syntax but prints a warning
| * | NAME-based restrictionsSitaram Chamarty2010-01-094-10/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Gitolite allows you to restrict changes by file/dir name. The syntax for this used "PATH/" as a prefix to denote such file/dir patterns. This has now been changed to "NAME/" because PATH is potentially confusing. While this is technically a backward-incompatible change, the feature itself was hitherto undocumented, and only a few people were using it, so I guess it's not that bad... Also added documentation now.
| * | Revert "easy install: needs a minor fix to accommodate auto-vivification"Sitaram Chamarty2009-12-301-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 6576e82e3342a869e18845df432ef4128e693131. On oddball configs, where the shell key is reused as the gitolite key by smart( people|-alecks), the ls-remote stops the program dead, preventing the "git add" and "git commit" that seed the admin repo. This makes extra work in terms of fixing it after the fact; removing it makes the install go further, and all you need to do is (1) delete the first line from ~/.ssh/authorized_keys on the server and (2) back on the client do a "git clone gitolite:gitolite-admin". OK so it needs to be removed. Explaining that was the easy part! The hard part is explaining why removing it is harmless. Look at the commit tree around that commit, and see that the commit before that (b78a720) was partially reverted in e7e6085. b78a720 removed the new_repo call from compile, forcing it to happen only on auth, which forced this workaround for seeding the admin repo. Since e7e6085 reverted that part of b78a720, giving back new_repo functions to compile, this line of code wasn't doing any good. QED and all that :)
| * | auth: regex goof on my partSitaram Chamarty2009-12-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | for those not yet able to upgrade (or until I merge this into the branch you care about), if you have a repo called, say "bk2git", just refer to it as "bk2git.git" in the clone command! [Thanks to Mark Frazer for finding this...]
| * | install transcriptSitaram Chamarty2009-12-251-0/+211
| |/
* | Fix exit codes for allowed ssh commandsTeemu Matilainen2010-01-102-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | gitolite specific ssh commands ("getperms", "setperms", "info" etc.) should exit with non-error code in case of success. Also "get/setperms" should print to STDOUT instead of STDERR. This change is specially needed for the gitolite-tools (http://github.com/tmatilai/gitolite-tools) to work. Signed-off-by: Teemu Matilainen <teemu.matilainen@reaktor.fi>
* | typo fix in doc/4; thanks Teemu!Sitaram Chamarty2010-01-081-1/+1
| |
* | Merge branch 'master' into wildreposSitaram Chamarty2009-12-234-3/+35
|\|
| * document @SHELL feature, allow "info" for all,Sitaram Chamarty2009-12-233-1/+33
| | | | | | | | | | ...but still distinguish shell folks with a small extra line telling them they have shell access
| * easy install: minor user message change for first-time installSitaram Chamarty2009-12-221-2/+2
| |
* | Merge branch '@all-for-repos' into wildreposSitaram Chamarty2009-12-214-28/+64
|\| | | | | | | | | Conflicts: src/gl-compile-conf
| * doc/3, conf: document @all for reposSitaram Chamarty2009-12-212-25/+50
| | | | | | | | plus some refactoring of doc/3
| * compile: support "repo @all" definitionsTeemu Matilainen2009-12-212-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "repo @all" can be used to set permissions or configurations for all already defined repos. (A repository is defined if it has permission rules associated, empty "repo" stanza or "@group=..." line is not enough.) For example to allow a backup user to clone all repos: # All other configuration [...] repo @all R = backup Signed-off-by: Teemu Matilainen <teemu.matilainen@reaktor.fi>
| * minor docfixSitaram Chamarty2009-12-211-2/+3
| |
* | parse_acl (gitolite.pm): minor convenience addedSitaram Chamarty2009-12-211-1/+6
| |
* | autoviv new repos by user only on "C" accessSitaram Chamarty2009-12-212-13/+9
| | | | | | | | | | | | | | | | | | | | | | | | we've removed the facility of auto-viving "W" access repos when they are not wildcards. A wildcard pattern like foo/CREATER was indistinguishable from a non-wildcard repo, and resolving it was becoming kludgier and kludgier. (See the revert in the commit before this one for details). As a side effect of not being able to distinguish wildcard repos from real repos easily, the expand command now works for a normal repo too (because we have to make it work for "foo/CREATER")
* | Revert "compile, parse_acl: treat foo/CREATER (no regex metas) correctly"Sitaram Chamarty2009-12-212-12/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 33fc0a7e9fe98dac1eec284119cf47509d68ab8c. Was causing too much trouble with access reporting (basic and expanded) because of the extra ^ at the start... The paranoia referred to in that commit was this sequence: - admin creates a named (non wildcard) repo using config file push - somehow that gets deleted (OS error, corruption, ...) - admin just asks anyone with a current repo to push it to auto-revive it (because we allow people with "W" access to non-wildcard repos to auto-viv repos) - if you're treating this the same as a wildcard creation, you end up making this guy the "creater" of that repo, which means he can add users etc... We resolve that paranois by disallowing autoviv of "W" access repos at all... Only "C" access repos can be autovived by a user (this will be in the next commit)
* | wildrepos: catch-all disclaimer for missing features ;-)Sitaram Chamarty2009-12-201-0/+8
| |
* | Merge branch 'master' into wildreposSitaram Chamarty2009-12-207-23/+56
|\| | | | | | | | | | | Conflicts: src/gitolite.pm src/gl-auth-command
| * compile: gitolite key as good as shell key for users in @SHELL groupSitaram Chamarty2009-12-192-2/+10
| | | | | | | | | | | | done by inserting a "-s" into the authkey forced command. (They also lose the "no-pty" restriction, for good measure!)
| * auth: (WDITOT?) allow special users to get a shellSitaram Chamarty2009-12-191-4/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ".../gl-auth-command username" is the normal command that authkeys forces, and this prevents that key from being used to get a shell. We now allow the user to get a shell if the forced command has a "-s" before the "username", like ".../gl-auth-command -s sitaram". (Now that a plain "ssh gitolite" gets you a shell, there's a new "info" command that such privileged keys can use to get basic access info). Thanks to Jesse Keating for the idea! I can't believe this never occurred to me before, but I guess I was so enamoured of my "innovation" in converting what used to be an error into some useful info I didn't think a bit more :/
| * allow '+' as valid character in user/reponamesSitaram Chamarty2009-12-181-2/+2
| |
| * auth: set umask when autoviv-ing reposSitaram Chamarty2009-12-171-2/+4
| | | | | | | | | | | | | | | | | | | | Looks like I'd forgotten this when I did the autoviv code. Repos created via gl-compile (when you add a new repo to the config file and push) worked fine, but repos created via gl-auth (when you autoviv a repo, wild or not) did not. This *should* be merged into wildrepos soon after testing; wildrepos will have a lot more autoviv-ing than master.
| * auth/install/pu-hook: pass ADMINDIR and BINDIR via ENVSitaram Chamarty2009-12-175-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | The admin repo's post-update hook needs to know where $GL_ADMINDIR is, and we had a weird way of doing that which depended on gl-install actually munging the hook code. We also always assumed the binaries are in GL_ADMINDIR/src. We now use an env var to pass both these values. This removes the weird dependency on gl-install that the post-update hook had, as well as make running other programs easier due to the new $GL_BINDIR env var.
| * minor docfixSitaram Chamarty2009-12-131-4/+4
| |