The initial fetch of a new repo which has 'upstream' read-only mirroring
configured will cause a spurious error concerning FETCH_HEAD not yet
existing. This silences the error.
while we're about it, add the same check to some of the internal
routines, so that commands can also be protected.
finally, just to make sure we don't lose it again in some other fashion,
add a few tests for path traversal...
before this, trying to access a wild repo would create an empty hash in
%repos. This is pretty harmless, but at some later point, memberships()
would try to use that in a pattern, attempting to match the real repo
being access-checked.
Which is still fine if your repo doesn't look like "libstdc++" AND
you're using some recent perl.
However, for perl 5.8.8, and if the repo has a ++ in it, perl barfs.
Here's a test program to check your perl:
#!/usr/bin/perl
$base="foo/u1/libstdc++";
$i="foo/u1/libstdc++";
if ( $base =~ /^$i$/ ) {
print 1;
} else {
print 2;
}
On 5.14.2 I get "2". On 5.8.8 I get:
Nested quantifiers in regex; marked by <-- HERE in m/^foo/u1/libstdc++ <-- HERE $/ at ./aa.pl line 6.
gitolite does indeed try to not load itself twice, but I forgot that by
that time the pwd is ~/.gitolite/conf not ~/.gitolite so it always ended
up reading itself twice in case of a wildcard include.
Add a special variable `%GL_CREATOR` to the the git-config trigger that
is replaced by the name of the repository creator (if any).
This can be useful to set up the default owner configuration for wild
repositories.
Example:
repo assignments/CREATOR/a[0-9][0-9]
C = @students
RW+ = CREATOR
config gitweb.owner = %GL_CREATOR
----
committer added an if condition to the s/// line.
Only '+' sign was unescaped in `http_simulate_ssh_connection()`.
When user translates `ssh git@host perms <repo> + <role> <user>` to
`curl https://host/git/perms?<repo>+%2b+<role>+<user>` nothing happens.
This commit fixes it modifying url unescaping.
committer notes: changed the regex per 'man URI::Escape'
(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
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'.
