{"thread":{"id":"22513","subject":"[gitolite] symlink hooks instead of copying them","startedAt":"2010-02-03T20:47:23Z","lastAt":"2010-02-04T06:34:47Z","messageCount":8,"participants":["martin f krafft","Sitaram Chamarty","Bill Lear"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"133533","messageId":"20100203204723.GA30157@lapse.rw.madduck.net","threadId":"22513","inReplyTo":null,"subject":"[gitolite] symlink hooks instead of copying them","fromName":"martin f krafft","fromEmail":"madduck@debian.org","sentAt":"2010-02-03T20:47:23Z","receivedAt":"2010-02-03T20:47:23Z","isPatch":false,"sender":{"key":"madduck@debian.org","avatar":null},"body":"Dear Sitaram, dear Teemo, dear gitolite-fans,\n\nGitolite currently copies hooks to repositories. For upgrades, it\nmust thus ensure that all hooks are also upgraded.\n\nIt occurs to me that this might be easier done using symlinks, or\nwith a file that includes the master hook(s) in\n~/.gitolite/src/hooks. Then, the hooks just have to be upgraded in\none place.\n\nDo you see a reason not to do this via symlinks?\n\n-- \n .''`.   martin f. krafft <madduck@d.o>      Related projects:\n: :'  :  proud Debian developer               http://debiansystem.info\n`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org\n  `-  Debian - when you have better things to do than fixing systems\n \n\"we are trapped in the belly of this horrible machine,\n and the machine is bleeding to death.\"\n                                        -- godspeed you black emperor!\n"},{"id":"133561","messageId":"20100204012840.GC497@atcmail.atc.tcs.com","threadId":"22513","inReplyTo":"20100203204723.GA30157@lapse.rw.madduck.net","subject":"Re: [gitolite] symlink hooks instead of copying them","fromName":"Sitaram Chamarty","fromEmail":"sitaram@atc.tcs.com","sentAt":"2010-02-04T01:28:40Z","receivedAt":"2010-02-04T01:28:40Z","isPatch":false,"sender":{"key":"sitaram@atc.tcs.com","avatar":null},"body":"On Thu, Feb 04, 2010 at 09:47:23AM +1300, martin f krafft wrote:\n> Dear Sitaram, dear Teemo, dear gitolite-fans,\n> \n> Gitolite currently copies hooks to repositories. For upgrades, it\n> must thus ensure that all hooks are also upgraded.\n> \n> It occurs to me that this might be easier done using symlinks, or\n> with a file that includes the master hook(s) in\n> ~/.gitolite/src/hooks. Then, the hooks just have to be upgraded in\n> one place.\n> \n> Do you see a reason not to do this via symlinks?\n\nIf you mean just the gitolite-specific hooks (the update\nhook for all repos, and the post-update hook for the admin\nrepo) then no problem.\n\nThe other hooks I'd rather not assume anything about.  The\ncurrent scheme forces an overwrite of the gitolite-specific\nhooks, as well as any hooks given in src/hooks, each time an\n\"install\" is done.  It does not touch any *other* hooks,\nwhich allows the admin to (via command line) place specific\nhooks in specific repos manually if he wishes to.\n\nI'm ok with symlinking stuff; a couple of \"cp\" commands\nwould change to \"ln\" :)  Let me try it out (and make sure it\nworks for upgrades also...)\n"},{"id":"133563","messageId":"20100204013556.GA2590@atcmail.atc.tcs.com","threadId":"22513","inReplyTo":"20100203204723.GA30157@lapse.rw.madduck.net","subject":"Re: [gitolite] symlink hooks instead of copying them","fromName":"Sitaram Chamarty","fromEmail":"sitaram@atc.tcs.com","sentAt":"2010-02-04T01:35:56Z","receivedAt":"2010-02-04T01:35:56Z","isPatch":false,"sender":{"key":"sitaram@atc.tcs.com","avatar":null},"body":"On Thu, Feb 04, 2010 at 09:47:23AM +1300, martin f krafft wrote:\n> Dear Sitaram, dear Teemo, dear gitolite-fans,\n> \n> Gitolite currently copies hooks to repositories. For upgrades, it\n> must thus ensure that all hooks are also upgraded.\n\nI forgot... part of the reason this \"copy all hooks over\neach time you run install\" is also to give people an easy\nway to update the hooks when the repo was *copied* from\nelsewhere, and not *created* by gitolite in the first place.\n\nBasically I'm paranoid about that \"update\" hook, without\nwhich the branch level access control doesn't work at all.\n\nSo this will still need to be done. Or you'll have to\nprovide some other command that will sweep through all repos\nin the $REPO_BASE and check that the symlink is pointing to\nthe right place etc etc.\n\nAny other ways of doing this?  I'd rather keep it as is, if\nit's OK with you, except for changing the cp to ln of course.\n"},{"id":"133564","messageId":"20100204014657.GA10114@lapse.rw.madduck.net","threadId":"22513","inReplyTo":"20100204013556.GA2590@atcmail.atc.tcs.com","subject":"Re: [gitolite] symlink hooks instead of copying them","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2010-02-04T01:46:57Z","receivedAt":"2010-02-04T01:46:57Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1428 +1300]:\n> I'm ok with symlinking stuff; a couple of \"cp\" commands\n> would change to \"ln\" :)  Let me try it out (and make sure it\n> works for upgrades also...)\n\nln -sf even.\n\n\n\nalso sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1435 +1300]:\n> I forgot... part of the reason this \"copy all hooks over each time\n> you run install\" is also to give people an easy way to update the\n> hooks when the repo was *copied* from elsewhere, and not *created*\n> by gitolite in the first place.\n> \n> Basically I'm paranoid about that \"update\" hook, without which the\n> branch level access control doesn't work at all.\n\nWouldn't it thus make sense to check during authentication that the\nsymlink exists and points to the right file, and to deny access\ncompletely if that isn't the case?\n\n> So this will still need to be done. Or you'll have to provide some\n> other command that will sweep through all repos in the $REPO_BASE\n> and check that the symlink is pointing to the right place etc etc.\n\nHaving a mass-update command for this might be nice, but I suppose\nit's also a trivial shell one-liner...\n\n  for i (**/*.git/hooks/update) \\\n    ln -sf ~git/.gitolite/src/hooks/update $i\n\n(this is zsh, not sure bash can do this yet)\n\n-- \nmartin | http://madduck.net/ | http://two.sentenc.es/\n \napt-get source --compile gentoo\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"133577","messageId":"20100204032239.GA5429@atcmail.atc.tcs.com","threadId":"22513","inReplyTo":"20100204014657.GA10114@lapse.rw.madduck.net","subject":"Re: [gitolite] symlink hooks instead of copying them","fromName":"Sitaram Chamarty","fromEmail":"sitaram@atc.tcs.com","sentAt":"2010-02-04T03:22:39Z","receivedAt":"2010-02-04T03:22:39Z","isPatch":false,"sender":{"key":"sitaram@atc.tcs.com","avatar":null},"body":"On Thu, Feb 04, 2010 at 02:46:57PM +1300, martin f krafft wrote:\n> also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1428 +1300]:\n> > I'm ok with symlinking stuff; a couple of \"cp\" commands\n> > would change to \"ln\" :)  Let me try it out (and make sure it\n> > works for upgrades also...)\n> \n> ln -sf even.\n\nyup...\n\n> also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1435 +1300]:\n> > I forgot... part of the reason this \"copy all hooks over each time\n> > you run install\" is also to give people an easy way to update the\n> > hooks when the repo was *copied* from elsewhere, and not *created*\n> > by gitolite in the first place.\n> > \n> > Basically I'm paranoid about that \"update\" hook, without which the\n> > branch level access control doesn't work at all.\n> \n> Wouldn't it thus make sense to check during authentication that the\n> symlink exists and points to the right file, and to deny access\n> completely if that isn't the case?\n\nYeah I guess that's easy enough really... just need to\ninclude a way to tell the code what is the right file to\npoint to.  (Currently it's all inside $GL_ADMINDIR but in\nthe APT case that may not be true...?)\n\n> Having a mass-update command for this might be nice, but I suppose\n> it's also a trivial shell one-liner...\n> \n>   for i (**/*.git/hooks/update) \\\n>     ln -sf ~git/.gitolite/src/hooks/update $i\n> \n> (this is zsh, not sure bash can do this yet)\n\nThis has to work on systems that don't even have bash (like\nplain old sh personality of ksh), leave alone zsh :)\n\nNot saying it's hard; just a \"find\" in backticks.  I'd still\nrather put it inside the perl code somewhere that already\ngets run anyway, as it is now...\n"},{"id":"133583","messageId":"20100204041318.GD13411@lapse.rw.madduck.net","threadId":"22513","inReplyTo":"20100204032239.GA5429@atcmail.atc.tcs.com","subject":"Re: [gitolite] symlink hooks instead of copying them","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2010-02-04T04:13:18Z","receivedAt":"2010-02-04T04:13:18Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1622 +1300]:\n> > Wouldn't it thus make sense to check during authentication that\n> > the symlink exists and points to the right file, and to deny\n> > access completely if that isn't the case?\n> \n> Yeah I guess that's easy enough really... just need to include\n> a way to tell the code what is the right file to point to.\n> (Currently it's all inside $GL_ADMINDIR but in the APT case that\n> may not be true...?)\n\nHow about comparing the hash sums of where you think the file is?\nThis would also ensure that repo access was disallowed if the hook\nhasn't been upgraded without symlinks (though I think the symlinks\nare still better than copies, and more expressive too). Does that\nfit your level of security-paranoia? ;)\n\nAbout the APT case — leave that to us. If we distribute gitolite\nfrom /usr/share/gitolite, then we'll probably be patching the entire\nsource anyway. Obviously, if it proves viable, then it might make\nsense to bring back that functionality and have it configurable at\ninstall or runtime.\n\n> This has to work on systems that don't even have bash (like plain\n> old sh personality of ksh), leave alone zsh :)\n> \n> Not saying it's hard; just a \"find\" in backticks.  I'd still\n> rather put it inside the perl code somewhere that already gets run\n> anyway, as it is now...\n\nNo objection.\n\nThanks!\n\n-- \nmartin | http://madduck.net/ | http://two.sentenc.es/\n \ntempt not a desperate man.\n                                                -- william shakespeare\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"133587","messageId":"19306.26226.369115.104150@blake.zopyra.com","threadId":"22513","inReplyTo":"20100204014657.GA10114@lapse.rw.madduck.net","subject":"Re: [gitolite] symlink hooks instead of copying them","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2010-02-04T06:17:22Z","receivedAt":"2010-02-04T06:17:22Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Thursday, February 4, 2010 at 14:46:57 (+1300) martin f krafft writes:\n>also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1428 +1300]:\n>> I'm ok with symlinking stuff; a couple of \"cp\" commands\n>> would change to \"ln\" :)  Let me try it out (and make sure it\n>> works for upgrades also...)\n>\n>ln -sf even.\n\nDoes 'ln -sf' work reliably on all distros?  I seem to recall on Ubuntu\n7.10 that this was broken.\n\n\nBill\n"},{"id":"133590","messageId":"20100204063447.GA16106@lapse.rw.madduck.net","threadId":"22513","inReplyTo":"19306.26226.369115.104150@blake.zopyra.com","subject":"Re: [gitolite] symlink hooks instead of copying them","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2010-02-04T06:34:47Z","receivedAt":"2010-02-04T06:34:47Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Bill Lear <rael@zopyra.com> [2010.02.04.1917 +1300]:\n> Does 'ln -sf' work reliably on all distros?  I seem to recall on Ubuntu\n> 7.10 that this was broken.\n\nunlink && symlink in Perl is probably preferably anyway.\n\n-- \nmartin | http://madduck.net/ | http://two.sentenc.es/\n \nbecause light travels faster than sound,\nsome people appear to be intelligent,\nuntil you hear them speak.\n \nspamtraps: madduck.bogus@madduck.net\n"}]}