also sprach [EMAIL PROTECTED] <[EMAIL PROTECTED]> [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 [EMAIL PROTECTED] <[EMAIL PROTECTED]> [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:"; [EMAIL PROTECTED] invalid/expired pgp (sub)keys? use subkeys.pgp.net as keyserver! spamtraps: [EMAIL PROTECTED] 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)
_______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
