Re: [gitolite] symlink hooks instead of copying them

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



also sprach Sitaram Chamarty <sitaram@xxxxxxxxxxx> [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@xxxxxxxxxxx

Attachment: digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]