Re: [Gnu-arch-users] Re: Re: Re: Future of GNU Arch, bazaar and bazaar-ng ... ?

[jblack]

On Tue, Aug 23, 2005 at 12:18:51AM +0200, martin f krafft wrote:
> > Not to pick nits, but hooks aren't arbitrary code. They're code that
> > traditionally the user himself has written. 
> 
> also sprach address@hidden <address@hidden> [2005.08.22.2221 +0200]:
> > Martin, tell me it's not so?
> 
> The point is this: I maintain a larger number of archives for ~ and
> /etc and effectively it's just myself committing. But I use in the
> order of 5 machines regularly, depending on where I am. It's
> a massive pain to synchronise the hooks back and from right now.
> Sure, I set up another repository for that, but it's the same beef
> I have with build-configs. Why should a repository with configs or
> hooks have to be changed for every change to any project? Why not
> let the project itself manage it?

Because people are very likely to pull things that they don't directly
own. With automatic hooks, its no longer safe to even look at a branch.

I can imagine a perfect storm if:

  1. there were a central location in which anybody could upload branches
  2. there was an automated registry service of some sort
  3. bazaar 2 (bzr) automatically downloaded downloaded branches
  4. hooks in downloaded branches were automatically executed.

Surely it would be better to make a wrapper that did the pull and ran the
code on your behalf? 

> What's the problem with in-archive hooks? I could just as well hide
> a trojan in the source and expect you to execute it during the next
> test run. If you think that won't go undetected, well, good. But by
> the same argument, a hook would be equally versioned and malicious
> code would be identified by conscious users inspecting diffs before
> merging foreign code.

The difference between hiding a trojan in the source and hiding the trojan
in a hook is monumental. A well designed hook system would allow one to
hook in to a variety of things -- not just commit. Here's some 
potentially useful non-commit hooks to give the idea:

pull - a hook change permissions for a tree after the pull
diff - a hook to ensure that ppp0 is up


With hooks in the archive, then one has to ensure that hooks are only
allowed in places where people have had a reasonable time to study the
hooks in place. That would mean no pull hook, no diff hook, etc.

> Have hooks that run only when I give them permission to. Have baz
> inform me of hooks that are unauthorised. Where's the problem?

You can do that (and everything else you want above) already, by editing
the main hook to call hooks stored in the archive.  :) 


  
> -- 
> martin;              (greetings from the heart of the sun.)
>   \____ echo mailto: !#^."<*>"|tr "<*> mailto:"; address@hidden
>  
> invalid/expired pgp (sub)keys? use subkeys.pgp.net as keyserver!
> spamtraps: address@hidden
>  
> an egg has the shortest sex-life of all: if gets laid once; it gets
> eaten once. it also has to come in a box with 11 others, and the
> only person who will sit on its face is its mother.



> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnu-arch-users
> 
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/

-- 
 James Blackwell      |   Life is made of the stuff that hasn't killed
 Tell someone a joke! |   you yet.                       - yours truly
----------------------------------------------------------------------
GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400