Sometime after v3.2, I fixed what looked like an information disclosure
issue, where a user could determine if an arbitrary repo existed or not,
even if he had no rights to see the repo. This was:
96cc2ea "new features relating to creating wild repos:"
Unfortunately, this appears to have broken gl-perms propagation to
slaves, because now running "perm -c" on an existing repo dies!
If you run
git diff 96cc2ea^ <this commit> -- src/commands/perms
you'll see how simple the fix *should* have been :-(
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!)
Still, I would advise caution if you use this as a basis for deleting
repos from the file system. A bug in this program could cause you to
lose important data!
Explicitly set "Content-Type: text/plain" for gitolite commands when
issued over http, so that it is possible to see the output with normal
browsers.
(At least) Apache httpd might set the Content-Type to something
different and triggers a download instead of showing the text directly.
Signed-off-by: Sven Strickroth <email@cs-ware.de>
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.
another of those "duh! what was I thinking" moments, this specific one
being "why test that files/directories are created with the right user
and group IDs? Shouldn't that be out of your control, as well as
totally unnecessary on a sane system?"
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.
