On Mon, Oct 13, 2008 at 02:06:03PM -0700, Jason Dagit wrote: > On Mon, Oct 13, 2008 at 11:11 AM, David Roundy <[EMAIL PROTECTED]> wrote: > > Hi all (and Jason in particular), > > > > This is a proposed change that needs to be discussed. I have never > > cared for the --run-posthook and --run-prehook flags (and > > --prompt-posthook and --prompt-prehook), and would prefer to remove > > them. > > I think we should have --disable-posthook (or whatever it's > currently named) for the same reason we have --no-test. If we have > the disable option, perhaps we should keep --run-posthook for > symmetry regardless of the default behavior?
I didn't remove --no-posthook (or propose to remove it). Its opposite is --posthook. > Again, regardless of the default behavior, --prompt-posthook is nice for the > same reason as --disable-posthook and the reason to have -i in rm as you > point out. If I recall correctly, --prompt-posthook shows you the command > before running it and alerts you to the fact that it's about to happen. > This is particularly useful in the case where you get a new repository and > you're working with it. I know how to change the default behavior locally, > so again, I argue for this regardless of the default. In the case where you get a new repository, it won't have any posthooks for which you might be prompted, though. And if you define a posthook, I don't see why you would want to be prompted for it. The exception, I suppose, is when you run darcs in someone else's repository. But of course, in that case that malicious person (who has an account on my machine) can specify --run-posthook in the defaults file. And similarly, I can specify --no-posthook on the command line for safety. > As I mention below, I don't think they serve a valid security > > feature. If you allow a hostile user to call darcs with an arbitrary > > command line, that user can add both --posthook='rm -rf ~' and > > --run-posthook at the same time. Ditto for hostile users who are able > > to modify your defaults file. > > I guess it depends on the interaction between prefs and commandline > options. When I added this I didn't really get how a push works > interms of the remote apply. I seem to recall thinking it would > help make it possible to make a push more secure, or at least this > could be used to keep it from becoming less secure. But, as you > point out, things like 'darcs push' cannot be secured. And in fact, this option can't be used to make *anything* more secure. Since it might *look* like it makes things more secure, if anything it will make them less secure (e.g. if users assume that darcs won't run prehooks or posthooks because they have ALL --prompt-posthook in their ~/.darcs/defaults, and therefore fearlessly run darcs whatsnew in the repository of their evil nemesis). > > So it isn't a possible security feature, but just a "safety" > > feature (like rm -i). But I'm also unable to imagine a scenario > > where someone "accidentally" calls --posthook, or accidentally > > adds it to their defaults file. Which just leaves it as an > > annoyance, and I'm annoyed by it, so I'd rather just remove the > > feature. > > Why don't we just change the default behavior? I don't see why we > should remove this safety feature. I guess if we change the default > then perhaps the flag --run-posthook is unneeded, but disable and > prompt still seem useful much like --no-test and rm -i. I just don't see a scenario in which someone would want to use this feature, and it'd be nice to have fewer options. David _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
