[MERGE][RFC] Enhanced hooks

Ian Clatworthy ian.clatworthy at internode.on.net
Wed Feb 6 07:57:02 GMT 2008


Aaron Bentley wrote:

> Until I read your wiki page, I did not realize you were contemplating
> hooks in branch.conf.  Since this file may be controlled by another
> user, this opens the door to malicious activity.  It's something I tried
> very hard to guard against happening, which is why gpg_signing_command
> cannot be specified in branch.conf.
> 
> Should anyone pursue the idea of configuration files, I strongly suggest
> that branch.conf be considered untrusted by default.

Jelmer,

Finding the hooks to run from that location (and that location only) is
a feature of shell-hook plugin. It sounds like we need some large
warnings put in the README in the short term, yes?

Aaron,

Do you have ideas on how we ought to support "run this hook for all
users accessing this branch"?

W.r.t. security, do you see using a hooks/ directory within .bzr for a
branch safer than branch.conf or not? It seems cleaner in that the hook
code is part of the branch, not just the hook command, but both ways are
equally unsecure, yes?

One of the reasons why I like using config files over directories is
because putting hook commands inside locations.conf - leveraging the
pattern matching we provide when processing that file - has a lot of
potential to lower cost of ownership. For our existing Python hooks, one
can always put config setting there and call back into the config
infrastructure to check whether to run or not. It's doable, though ugly
in the eyes of some (like me). External scripts are different: we don't
want the cost of executing them unnecessarily and we don't want the
complexity of calling back from them into our API as a rule. Any
suggestions on how to provide this flexibility if we go the "find hooks
in a directory" route?

Ian C.



More information about the bazaar mailing list