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.

doc/mirroring.mkd

@@ -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
+      * Permission changes will only propagate on the next 'git push'.  Of
-        work.
+        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 :-)

src/lib/Gitolite/Triggers/Mirroring.pm

@@ -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;