(manually tested)
- new rc var: GL_BINDIR2; see doc update in this commit
- added _which() function to search both $GL_BINDIR and $GL_BINDIR2
- 'gitolite <command>', non-perl triggers, VREFs, and sugar, use this
- unshifted $GL_BINDIR2/lib into @INC upfront in Rc.pm
- perl triggers use this
- git version bumps up, causes minor change in t/merge-check.t
- for some strange reason apache cannot see /tmp/gitolite-http-authuserfile
(I thought private /tmp was only if you enabled selinux...)
i.e., a client fetch will invoke the push, (subject to 'nice' setting),
but you can also force a fetch regardless of last fetch time by running
this command directly on the server:
gitolite ../triggers/upstream fetch <reponame>
Also, use FETCH_HEAD instead of own sentinel file (idea courtesy Luke Lu)
'gitolite query-rc' now only queries one variable at a time. That is,
you cannot do something like this:
gitolite query-rc UMASK GL_ADMIN_BASE
to query both variables. I think this is rarely used, plus it is easy
to work-around (just run two separate commands), so it was sacrificed
for the ability to do this:
gitolite query-rc -q COMMANDS fork
which tells you whether $rc{COMMANDS}{fork} exists or not.
If a user has multiple keys, ssh-authkeys-shell-users will only add the
"-s" flag to the first key it finds. Change the substitution to apply
to all matching lines and hence grant shell access to all of the user's
keys.
Signed-off-by: John Keeping <john@keeping.me.uk>
- fix docs to explicitly state that mirroring wild repos is a bad idea
if the authentication data is not the same on the peers.
- an important check against a malicious peer was missed out. If
people heed the warning above this check is not really needed but it
is good for completeness.
- warning about redirected pushes removed, thanks to Ronald Ip having
tested it and reported it working.
It creates the repo on the remote side (getting the creator name from
the gl-creator file and sending it across), as well as sending gl-perms
on subsequent connections.
This has only been minimally tested. E.g., complex setups or asymmetric
configs on master and slave, etc. have NOT been tested.
This has also not been tested with redirected pushes.
repo foo
desc = "foo"
RW = u1
...etc...
The order of the clauses was parsing this like the old 'reponame = "some
description"' and end up creating a repo called 'desc'!
It would also, as a side-effect, change the repo so what you thought
were access rules for 'foo' would become access rules for 'desc'.
Although this is not a "hole" that allows a normal user to bypass
controls, I still consider this a hole in the sense that I want to
separate "admin push" rights from "shell access on server" rights.
(I realise that most people don't make this distinction, but I do, and
for me and most sites I consult for it is important).
Thanks to drue on #gitolite who pointed it out excitedly, and apologies
for killing what he thought of as a feature!
