sean finney <[EMAIL PROTECTED]> writes: > is there any reason why this issue couldn't be solved by amending > policy (or just simply patching dpkg-source) to require that > "debian/rules patch" (or some less commonly used name if we're > worried about existing implementations of this rule) is called as > part of the unpacking process or a source package? just a thought...
One good reason I can think of is that you're then running unknown code as part of unpacking the source. It's no security risk to unpack a tarball, apply a patch to it via GNU 'patch', and examine the result. (I don't even have to trust debhelper for that, since it's not part of unpacking the source.) I'm *not* happy to need to run some target with arbitrary commands in the 'debian/rules' file, just to allow me to examine the source. A big part of the reason for unpacking the source could be to find out what's in there *before* executing any part of it. -- \ "[T]he speed of response of the internet will re-introduce us | `\ to that from which our political systems have separated us for | _o__) so long, the consequences of our own actions." —Douglas Adams | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
