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 would happen if @all was used but no actual groups were defined,
and would in turn cause a parse error on the compiled conf because it
now ends with a 'false'.
thanks to Jelle Raaijmakers
- new 'create' command for explicit creation
- new 'AutoCreate' trigger to prevent auto-creation on read operations
or both read and write operations
- a few related fixups to the perms command
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.
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
'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.
- 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!
Sitaram Chamarty
gitolite tester
Olof Johansson