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

[martin f krafft]

also sprach address@hidden <address@hidden> [2005.08.22.2221 +0200]:
> Not to pick nits, but hooks aren't arbitrary code. They're code that
> traditionally the user himself has written. 

Na, *one* of the users has written it. I may have told the hook to
rm -rf /home iff user == jblack...

also sprach address@hidden <address@hidden> [2005.08.22.2313 +0200]:
> > Hooks in the way Bazaar manages them (~/.arch-params/hook), yes.
> > But Martin was asking for a hook managed in the archive itself.
> > In this case, you can't trust the code by default (the wiki
> > desribes a way to store the hook in the working tree, actually).
> 
> /me feels his jaw drop in shock
> 
> Martin, tell me it's not so?

It is (he says and pushes the jaw back up).

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?

Look at Debian: we don't ship e.g. logrotate with a bunch of files
to do all the different things logrotate does for whatever daemon
may be installed. Instead, the packages register their own scripts.
logcheck started out packaging stuff for a lot of other packages,
but the tendency was to move things to the packages. I want to
maintain a hook script, to e.g. push a web site up to the http server
as part of the commit, as part of the web site's archive. While my
own motivation would be convenience, it's surely a usability problem
in my eyes:

I spend almost 3 hours the other day explaining arch to a colleague
who is to work on a project with me stored in arch. When he finally
understood branches, I hit him with build configs and he didn't like
the extra layer. Now I have to teach him hooks and how to maintain
them, and it's not going to be easy.

I understand the security concern. I could author code that you
would execute as part of your commit. That's why we need integrity
checks and authorisation, by means of crypto for instance. I am not
sure how to implement this, but I really don't see why I can't just
check out an archive and use it the way it was intended to be used,
but have to set up build configs and hooks in addition.

I hear git has a feature of tagging in a way invisible to others.
Something similar for hooks would be sweet: I maintain my hook for
archive foo in foo and for bar in bar, but others don't need to
worry about it. On the flipside, it would be even nicer if I could
configure the hook such that others can also use it. Or even
configure it so that others must use it. Think integrity checks, log
message verification, unit test runs, etc. etc.

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.

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

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

signature.asc
Description: Digital signature (GPG/PGP)