Re: How to cope with patches sanely
sean finney <firstname.lastname@example.org> 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 |