[MERGE][RFC] Enhanced hooks

[John Arbash Meinel]

Ian Clatworthy wrote:
> 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?

Yes, they are both equally insecure.


> 
> 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.
> 
> 

Actually, for some, branch.conf represents lower cost. Specifically 
thing a large company with a lot of branches wanting to enforce some 
company policy.
To go one step further, how about "encourage" company policy. They could 
always get around it, but the point is to *help* them do the right thing.

That is actually one of the reasons Monty wanted to put the config files 
in .bzr-<plugin>/default.conf or possibly .bzr-plugins/plugin.conf

It would be a way to version them which makes it easier to send them to 
the end-users.

Remember that while centralized version control is "evil and wrong" :) 
it does allow a single administrator to set things up for a bunch of people.

Hooks often fall into this "everyone should follow X" rules.

My personal preference is to provide enough core support so that a 
3rd-party can write a plugin which does the "trust settings in branches" 
for places that they want their users to trust. That way it doesn't have 
to be trusted everywhere, and hopefully we don't have to get too 
involved in hook ACLs and trust mechanisms.

Consider, one solution would be to require hooks to be gpg signed, and 
then give a list of keys that you are willing to trust the hooks. It 
would be possible, but it really starts adding a lot of complexity. I 
think it is far easier to have someone install the "site-configuration 
for company Foo" plugin.

John
=:->