Not following through on instructions to remove a repo, per [1], is not
sufficient. Even if you did just the first step, the repo should no
longer be accessible. See [2] for discussion.
As a bonus, we get rid of one pesky warning that always confused people.
(In hindsight -- this confusion itself should have been a warning that
something is wrong and needed fixing!)
[1]: http://sitaramc.github.com/gitolite/repos.html
[2]: http://groups.google.com/group/gitolite/browse_thread/thread/a3d4c3e917056abb
please remember we make up words here, like refex was a word we created
to mean "a regex that matches a ref".
A "bugly", then, is a bug that's merely ugly (and not a real problem!)
This might actually make the redis version unnecessary for most people!
And if it does, well shame on me for not instrumenting things at a more
granular level before going all "oh we need a cache!"
[In my defense, I blame redis for being such a sweet little tool that I
felt compelled to use it somehow!]
----
t/sequence failed because the test itself was in error; fixed.
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.
(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
Sitaram Chamarty