git-cvsserver is analogous to git-receive-pack; a checking from a cvs client to a central server is like a git-push from a working repository. Therefore it's nice to use the same access control (and email sending) that a receive-pack would perform.
This patch tests for an executable update hook; if it is it is run with the ref being updated and the old and new hashes as normal. If the update hook returns an error code the update is aborted and the ref is never updated.
Signed-off-by: Andy Parkins <andyparkins@gmail.com> --- I'm dubious whether this is the correct thing to do. It suits me for my circumstances and I'm arguing that git-cvsserver is more like git-receive-pack than git-commit; but internally it looks a lot more like git-commit.
Without calling the update hook though, git-cvsserver can completely bypass any extra access checks that git-receive-pack would have to perform. Assuming git-cvsserver is a central repository - I think it's correct to call the update hook rather than the pre-commit hook.
However, it's a judgement call, so I defer to someone with better judgement than me :-)
git-cvsserver.perl | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-)
Show changes to git-cvsserver.perl +15 −0
diff --git a/git-cvsserver.perl b/git-cvsserver.perl index 9371788..b4ef6bc 100755 --- a/git-cvsserver.perl +++ b/git-cvsserver.perl @@ -1171,6 +1171,21 @@ sub req_ci exit; } + # Check that this is allowed, just as we would with a receive-pack + my @cmd = ( $ENV{GIT_DIR}.'hooks/update', "refs/heads/$state->{module}", + $parenthash, $commithash ); + if( -x $cmd[0] ) { + unless( system( @cmd ) == 0 ) + { + $log->warn("Commit failed (update hook declined to update ref)"); + print "error 2 Commit failed (update hook declined)\n"; + close LOCKFILE; + unlink($lockfile); + chdir "/"; + exit; + } + } + print LOCKFILE $commithash; $updater->update();
-- 1.5.0.rc4.364.g85b1
