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
What happens is that running
ssh git@host perms reponame
appears to hang, since it is waiting for STDIN. I added a message to
help, since we don't want users losing files accidentally!
(The other alternative is to add a specific option for batch mode, but
this is backward incompatible for people who have scripts that may be
doing this).
thanks to Caleb Cushing for catching this
----
The "make sure Ctrl-C gets caught" thing needs some explanation.
Without it, a user could inadvertently lose his gl-perms file if he ran
the command in batch mode. You'd think that the Ctrl-C would hit the
for (<>) {
line and bail, but it manages to reach the
_print( $pf, @a );
line somehow. Even trapping SIG INT does not help.
I suspect it is to do with how signals are propagated by ssh across a
"no-pty" session, but am not sure.
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.
