<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Oct 13, 2008 at 11:11 AM, David Roundy <span dir="ltr"><<a href="mailto:droundy@darcs.net">droundy@darcs.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi all (and Jason in particular),<br>
<br>
This is a proposed change that needs to be discussed. I have never<br>
cared for the --run-posthook and --run-prehook flags (and<br>
--prompt-posthook and --prompt-prehook), and would prefer to remove<br>
them.</blockquote><div><br>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?<br>
<br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
As I mention below, I don't think they serve a valid security<br>
feature. If you allow a hostile user to call darcs with an arbitrary<br>
command line, that user can add both --posthook='rm -rf ~' and<br>
--run-posthook at the same time. Ditto for hostile users who are able<br>
to modify your defaults file.</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">So it isn't a possible security feature, but just a "safety" feature<br>
(like rm -i). But I'm also unable to imagine a scenario where someone<br>
"accidentally" calls --posthook, or accidentally adds it to their<br>
defaults file. Which just leaves it as an annoyance, and I'm annoyed<br>
by it, so I'd rather just remove the feature.</blockquote><div><br>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.<br>
<br>Thanks,<br>Jason<br></div></div><br></div>