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.
(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
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'.
(but change repo check to allow repoPATT instead of just repoNAME)
This is because there are/will be some situations where access() is
called without those two checks being done (i.e., it is not only from
src/commands/access that it is called).
(1) the backward compat breakage: you can't create empty-valued config
keys anymore. That is, you can't do the eqvt of the following shell
command using gitolite
git config foo.bar ""
(2) fixed a bug where this:
repo foo
config foo.bar =
when queried using
gitolite git-config -r foo .
would return even the empty valued ones, which -- remember! -- are
not supposed to exist anymore.
Fixing this bug allows situations like this to not show the admin
repo in gitweb:
repo [a-z].*
config gitweb.owner = P-h B
repo gitolite-admin
config gitweb.owner =
----
background...
Somewhere in g3 (well actually in 057506b), we lost the ability to
distinguish
config foo.bar = ""
from
config foo.bar =
I decided that conflating them is more intuitive for most people,
because a survey [1] revealed that no one seemed to want the equivalent
of the following shell command:
----
[1] ...of a (small prime greater than 1) number of people on #git
- minor typo fixes, clarifications, etc.
- keep sts.html url consistent, because many people link to
http://sitaramc.github.com/gitolite/sts.html
- create a common migration doc, so the old 'migr.html' does not 404
when g3 docs become "main"
- progit doc done
- add gitosis convert script (FWIW)
- a minor comment fix to Sugar.pm
