(about this commit)
The install doc now describes both the ways of installing gitolite.
It also has a handy appendix for package maintainers describing what
they need to do.
(about the "dps" -- distro packaging support -- commit series)
This commit is the last in the chain meant to make gitolite more
friendly for package maintainers.
Frankly, I never really thought gitolite would get big enough or
important enough for someone to package it, and I always did just
the bare minimum I needed to get it working, first for myself, then
anyone who hopped onto #git and asked. As a result, it had some
quirks in terms of what is expected where and so on...
Luckily, it didn't take a lot of changes to fix it, and this series
of commits should help make it very easy to package gitolite for
system-wide use.
The old install method will now use conf/VERSION instead of src/VERSION everywhere.
The new one, if you use the builtin make file to "make branch.tar" will also create just such a file
gl-install copies
- the initial rc file to ~/.gitolite.rc if it doesn't exist
- src and hooks to GL_ADMINDIR
Make it aware of a package-based setup sequence, where the above two
change somewhat; see code diff.
This should be the last bit of change needed to prepare gitolite setup
so that a distro package maintainer does not have to fiddle too much
with code inside.
(What remains is docs, and a setup script for server-side use, to
replace the latter part of easy install)
if you have read access to the admin repo, you can say
ssh git@server info user1 [...]
Original idea and code by Karteek E. The motivation is to quickly and
easily check what perms a user has. Technically nothing that you can't
glean from the config file itself but it serves as a double check or a
mild debugging aid perhaps.
However note that the branch level rules are much more complex and they
do not, as yet, have any such "helpful" aids. Life is like that
sometimes.
Gitolite allows you to set git repo options using the "config" keyword;
see conf/example.conf for details and syntax.
However, if you are in an installation where the repo admin does not
(and should not) have shell access to the server, then allowing him to
set arbitrary repo config options *may* be a security risk -- some
config settings may allow executing arbitrary commands.
This patch fixes it, introducing a new RC variable to control the
behaviour. See conf/example.gitolite.rc for details
Although I have washed my hands off the security aspect if you use
external commands, that doesn't mean I won't make them as tight as I can
;-) Right now, this is just a place holder -- if people use it and
complain that the pattern is too restrictive, I'll change it.
The wildrepos branch has been merged into master, and deleted. It will no
longer exist as a separate branch. Instead, a new variable
called $GL_WILDREPOS has been added which acts as a switch; when
off (which is the default), many wildrepos features are disabled.
(the "C" permissions, and the getperms (etc.) commands mainly).
Important: if you are using wildrepos, please set "$GL_WILDREPOS = 1;" in
the RC file when you upgrade to this version (or just before you do the
upgrade).
Allow users to set and display description (for gitweb) for their
own wildcard repositories using ssh commands:
setdesc <repo>
getdesc <repo>
Signed-off-by: Teemu Matilainen <teemu.matilainen@reaktor.fi>
brought on by realising that you lost $shell_allowed when refactoring
(previous commit) but perl hadn't caught it because -- damn -- you
didn't have "use strict" in gitolite.pm
lots of conflicts, esp in gl-auth-command, due to refactoring the
"special commands" stuff on master
Conflicts:
doc/3-faq-tips-etc.mkd
src/gitolite.pm
src/gl-auth-command
src/gl-compile-conf
great idea by Robin Smidsrød: since users are already capable of
authenticating themselves to gitolite via ssh keys, use that to let them
set or change their own HTTP passwords (ie, run the "htpasswd" command
with the correct parameters on behalf of the "git" user on the server)
code, rc para, and documentation. In fact everything except... ahem...
testing ;-)
and while we're about it, we also reorganised the way these helper
commands (including the venerable "info" are called)
Gitolite uses projects.list to set the owners for gitweb's use.
Unfortunately, this does not work for gitweb setups that set
$projectroot to a directory, thus generating the list of
repositories on the fly.
This patch changes that: gitolite now writes the gitweb.owner
configuration variable for each repository (and properly cleans up after
itself if the owner is removed).
The patch causes gitolite not to write the owner to projects.list
anymore, as this would be redundant.
The owner also needs no longer be escaped, so this patch removes the
poor man's 's/ /+/g' escaping previously in place.
Note that I am not a Perl coder. Thus there are probably better ways to
implement this, but at least it works.
Cc: Sitaram Chamarty <sitaramc@gmail.com>
Signed-off-by: martin f. krafft <madduck@madduck.net>
This is actually a pretty big deal, and I am seriously starting wonder
if calling this "gito*lite*" is justified anymore.
Anyway, in for a penny, in for a pound...
This patch implements a generic way to allow access control for external
commands, as long as they are invoked via ssh and present a server-side
command that contains enough information to make an access control
decision.
The first (and only, so far) such command implemented is rsync.
Please read the changes in this commit (at least the ones in conf/ and
doc/) carefully.
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.
- 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.
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!)
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.
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
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
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>
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>
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
(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
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.
This reverts commit 6576e82e33.
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 :)
