[gitolite] symlink hooks instead of copying them

[gitolite] symlink hooks instead of copying them

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

Dear Sitaram, dear Teemo, dear gitolite-fans,

Gitolite currently copies hooks to repositories. For upgrades, it
must thus ensure that all hooks are also upgraded.

It occurs to me that this might be easier done using symlinks, or
with a file that includes the master hook(s) in
~/.gitolite/src/hooks. Then, the hooks just have to be upgraded in
one place.

Do you see a reason not to do this via symlinks?

-- 
 .''`.   martin f. krafft <madduck@d.o>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"we are trapped in the belly of this horrible machine,
 and the machine is bleeding to death."
                                        -- godspeed you black emperor!

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gitolite] symlink hooks instead of copying them

[Sitaram Chamarty]

On Thu, Feb 04, 2010 at 09:47:23AM +1300, martin f krafft wrote:
> Dear Sitaram, dear Teemo, dear gitolite-fans,
> 
> Gitolite currently copies hooks to repositories. For upgrades, it
> must thus ensure that all hooks are also upgraded.
> 
> It occurs to me that this might be easier done using symlinks, or
> with a file that includes the master hook(s) in
> ~/.gitolite/src/hooks. Then, the hooks just have to be upgraded in
> one place.
> 
> Do you see a reason not to do this via symlinks?

If you mean just the gitolite-specific hooks (the update
hook for all repos, and the post-update hook for the admin
repo) then no problem.

The other hooks I'd rather not assume anything about.  The
current scheme forces an overwrite of the gitolite-specific
hooks, as well as any hooks given in src/hooks, each time an
"install" is done.  It does not touch any *other* hooks,
which allows the admin to (via command line) place specific
hooks in specific repos manually if he wishes to.

I'm ok with symlinking stuff; a couple of "cp" commands
would change to "ln" :)  Let me try it out (and make sure it
works for upgrades also...)

Re: [gitolite] symlink hooks instead of copying them

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1428 +1300]:
> I'm ok with symlinking stuff; a couple of "cp" commands
> would change to "ln" :)  Let me try it out (and make sure it
> works for upgrades also...)

ln -sf even.



also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1435 +1300]:
> I forgot... part of the reason this "copy all hooks over each time
> you run install" is also to give people an easy way to update the
> hooks when the repo was *copied* from elsewhere, and not *created*
> by gitolite in the first place.
> 
> Basically I'm paranoid about that "update" hook, without which the
> branch level access control doesn't work at all.

Wouldn't it thus make sense to check during authentication that the
symlink exists and points to the right file, and to deny access
completely if that isn't the case?

> So this will still need to be done. Or you'll have to provide some
> other command that will sweep through all repos in the $REPO_BASE
> and check that the symlink is pointing to the right place etc etc.

Having a mass-update command for this might be nice, but I suppose
it's also a trivial shell one-liner...

  for i (**/*.git/hooks/update) \
    ln -sf ~git/.gitolite/src/hooks/update $i

(this is zsh, not sure bash can do this yet)

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
apt-get source --compile gentoo
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gitolite] symlink hooks instead of copying them

[Sitaram Chamarty]

On Thu, Feb 04, 2010 at 02:46:57PM +1300, martin f krafft wrote:
> also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1428 +1300]:
> > I'm ok with symlinking stuff; a couple of "cp" commands
> > would change to "ln" :)  Let me try it out (and make sure it
> > works for upgrades also...)
> 
> ln -sf even.

yup...

> also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1435 +1300]:
> > I forgot... part of the reason this "copy all hooks over each time
> > you run install" is also to give people an easy way to update the
> > hooks when the repo was *copied* from elsewhere, and not *created*
> > by gitolite in the first place.
> > 
> > Basically I'm paranoid about that "update" hook, without which the
> > branch level access control doesn't work at all.
> 
> Wouldn't it thus make sense to check during authentication that the
> symlink exists and points to the right file, and to deny access
> completely if that isn't the case?

Yeah I guess that's easy enough really... just need to
include a way to tell the code what is the right file to
point to.  (Currently it's all inside $GL_ADMINDIR but in
the APT case that may not be true...?)

> Having a mass-update command for this might be nice, but I suppose
> it's also a trivial shell one-liner...
> 
>   for i (**/*.git/hooks/update) \
>     ln -sf ~git/.gitolite/src/hooks/update $i
> 
> (this is zsh, not sure bash can do this yet)

This has to work on systems that don't even have bash (like
plain old sh personality of ksh), leave alone zsh :)

Not saying it's hard; just a "find" in backticks.  I'd still
rather put it inside the perl code somewhere that already
gets run anyway, as it is now...

Re: [gitolite] symlink hooks instead of copying them

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]

also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1622 +1300]:
> > Wouldn't it thus make sense to check during authentication that
> > the symlink exists and points to the right file, and to deny
> > access completely if that isn't the case?
> 
> Yeah I guess that's easy enough really... just need to include
> a way to tell the code what is the right file to point to.
> (Currently it's all inside $GL_ADMINDIR but in the APT case that
> may not be true...?)

How about comparing the hash sums of where you think the file is?
This would also ensure that repo access was disallowed if the hook
hasn't been upgraded without symlinks (though I think the symlinks
are still better than copies, and more expressive too). Does that
fit your level of security-paranoia? ;)

About the APT case — leave that to us. If we distribute gitolite
from /usr/share/gitolite, then we'll probably be patching the entire
source anyway. Obviously, if it proves viable, then it might make
sense to bring back that functionality and have it configurable at
install or runtime.

> This has to work on systems that don't even have bash (like plain
> old sh personality of ksh), leave alone zsh :)
> 
> Not saying it's hard; just a "find" in backticks.  I'd still
> rather put it inside the perl code somewhere that already gets run
> anyway, as it is now...

No objection.

Thanks!

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
tempt not a desperate man.
                                                -- william shakespeare
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gitolite] symlink hooks instead of copying them

[Bill Lear]

On Thursday, February 4, 2010 at 14:46:57 (+1300) martin f krafft writes:
>also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1428 +1300]:
>> I'm ok with symlinking stuff; a couple of "cp" commands
>> would change to "ln" :)  Let me try it out (and make sure it
>> works for upgrades also...)
>
>ln -sf even.

Does 'ln -sf' work reliably on all distros?  I seem to recall on Ubuntu
7.10 that this was broken.


Bill

Re: [gitolite] symlink hooks instead of copying them

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

also sprach Bill Lear <rael@zopyra.com> [2010.02.04.1917 +1300]:
> Does 'ln -sf' work reliably on all distros?  I seem to recall on Ubuntu
> 7.10 that this was broken.

unlink && symlink in Perl is probably preferably anyway.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
because light travels faster than sound,
some people appear to be intelligent,
until you hear them speak.
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gitolite] symlink hooks instead of copying them

[Sitaram Chamarty]

On Thu, Feb 04, 2010 at 09:47:23AM +1300, martin f krafft wrote:
> Dear Sitaram, dear Teemo, dear gitolite-fans,
> 
> Gitolite currently copies hooks to repositories. For upgrades, it
> must thus ensure that all hooks are also upgraded.

I forgot... part of the reason this "copy all hooks over
each time you run install" is also to give people an easy
way to update the hooks when the repo was *copied* from
elsewhere, and not *created* by gitolite in the first place.

Basically I'm paranoid about that "update" hook, without
which the branch level access control doesn't work at all.

So this will still need to be done. Or you'll have to
provide some other command that will sweep through all repos
in the $REPO_BASE and check that the symlink is pointing to
the right place etc etc.

Any other ways of doing this?  I'd rather keep it as is, if
it's OK with you, except for changing the cp to ln of course.