deac
/
gitolite
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

fixup to pushing wild repos permissions... 

- 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.
redis
Sitaram Chamarty 2012-06-03 07:38:19 +05:30
parent 78866f6f28
commit db70595b87
2 changed files with 20 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
doc/mirroring.mkd
View File

@ -41,23 +41,28 @@ Gitolite extends this simple notion in the following ways:
prepared to receive updates from the master.
However, there is limited support for auto-creating wild card repos and
sending 'perms' info across, with the following caveats at present:
sending 'perms' info across, with the following caveats at present. (Some
of this text won't make sense unless you know what those features are).
* *WARNING: it does NOT make sense to mirror wild repos in setups where
the authentication data is not the same (i.e., where "alice" on the
master and "alice" on a slave maybe totally different people)*.
* This has only been minimally tested. For example, complex setups or
asymmetric configs on master and slave, etc. have NOT been tested.
* This has also not been tested with redirected pushes. It may not
work.
* Permission changes will only propagate on the next 'git push'. Of
course, if you know the name of the slave server, you can run
ssh git@host mirror push slave-server-name repo-name
* Using 'perms' on a slave is allowed but will neither propagate nor
persist. They will be overwritten by whatever perms the master has
(even if it is an empty set) on the next 'git push'.
* As with lots of extra features in gitolite, smart http support is not
on my radar. Don't ask.
* If you change permissions using the 'perms' command, they will only go
across on the next push. Or, if you know the name of the slave
server, you can run
ssh git@host mirror push slave-server-name repo-name
Please test it out and let me know if something surprising happens. Be
aware that I have been known to claim bugs are features if I don't have
time to fix them immediately :-)

10
src/lib/Gitolite/Triggers/Mirroring.pm
View File

@ -17,6 +17,11 @@ my ( $mode, $master, %slaves, %trusted_slaves );
sub input {
return unless $ARGV[0] =~ /^server-(\S+)$/;
# note: we treat %rc as our own internal "poor man's %ENV"
$rc{FROM_SERVER} = $1;
trace( 3, "from_server: $1" );
my $sender = $rc{FROM_SERVER} || '';
# custom peer-to-peer commands. At present the only one is 'perms -c',
# sent from a mirror command
if ($ENV{SSH_ORIGINAL_COMMAND} =~ /^CREATOR=(\S+) perms -c '(\S+)'$/) {
@ -26,6 +31,7 @@ sub input {
details($repo);
_die "$hn: '$repo' is local" if $mode eq 'local';
_die "$hn: '$repo' is native" if $mode eq 'master';
_die "$hn: '$sender' is not the master for '$repo'" if $master ne $sender;
# this expects valid perms content on STDIN
_system("gitolite perms -c $repo");
@ -34,10 +40,6 @@ sub input {
exit 0;
}
# note: we treat %rc as our own internal "poor man's %ENV"
$rc{FROM_SERVER} = $1;
trace( 3, "from_server: $1" );
if ( $ENV{SSH_ORIGINAL_COMMAND} =~ /^USER=(\S+) SOC=(git-receive-pack '(\S+)')$/ ) {
# my ($user, $newsoc, $repo) = ($1, $2, $3);
$ENV{SSH_ORIGINAL_COMMAND} = $2;