> On a different system where /root was world readable, the error was
> replaced with a warning:
> dpkg-source: warning: extracting unsigned source package (exe_1.04.1.3602-boss1.dsc)
> dpkg-source: info: extracting exe in exe-1.04.1.3602
> dpkg-source: info: unpacking exe_1.04.1.3602-boss1.tar.gz
> dpkg-source: warning: exe-1.04.1.3602/debian/rules does not exist
> I see several problems with this...
> When there is an error I would expect dpkg-source to clean up after
> itself, probably a --no-cleanup option needs adding though for people
> wanting to debug why the extraction failed.
I don't see the immediate need for this. It does this with temporary
files/dirs that it uses for example when it builds a package. But I don't
see why it should do this for non-temporary files...
> I don't understand why dpkg-source needs to look at debian/rules at all.
To make it executable.
> And more fundamentally, dpkg-dev should never extract or follow symlinks
> that point outside the source package. That includes all absolute ones
> and any relative ones with too many .. in their link target. Even if
> dpkg-source doesn't write to them during unpack, they could have some
> other impact on the user's system if they access them thinking that
> since Debian source packages are self-contained they should be safe.
dpkg-source delegates extraction to tar. It can't easily cherry-pick
what to extract...
dpkg-source already has code to not extract new/supplementary files
over already unpacked symlinks so that unpacking a source package can't
write files outside of the newly created directory.
What kind of bad impact do you expect ? The worst I can imagine is
something like "chmod -R" changing rights but apparently "chmod -R"
already ignores symlinks by default.
We should still do something to avoid chmodding() a file outside of the
unpacked source tree but I don't know whether it's just ensuring that
debian and debian/rules are not symlinks, or a more heavy analyzis to get
rid of all symlinks pointing outside of the source package.