[debhelper-devel] "Rules-Requires-Root: no" vs ExtUtils::Install + dh_strip_nondeterminism

[Mattia Rizzolo]

On Sat, Oct 28, 2017 at 02:21:37PM +0200, Axel Beckert wrote:
> Do I understand it correctly that with "Rules-Requires-Root: no" the
> root:root ownership is only set by dh_builddeb?

Well, by dpkg-deb of course :)
Check the --root-owner-group option of dpkg-deb 1.19.0.

> > > >    dh_strip_nondeterminism
> > > > dh_strip_nondeterminism: debian/systray-mdstat/usr/share/perl5/auto/share/dist/systray-mdstat/harddrivespare.png: debian/systray-mdstat/usr/share/perl5/auto/share/dist/systray-mdstat/harddrivespare.png: open: Permission denied at /usr/share/perl5/File/StripNondeterminism/handlers/png.pm line 60.
> > > >
> > > > debian/rules:5: recipe for target 'binary' failed
> > > > make: *** [binary] Error 13
> > > > dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
> > > 
> > > The file in question is read-only, but belongs to the user trying to
> > > build the package:
> > > 
> > > -r--r--r-- 1 abe abe 1749 Oct 27 22:48 debian/systray-mdstat/usr/share/perl5/auto/share/dist/systray-mdstat/harddrivespare.png
> [...]
> > > The culprit seems to be in ExtUtils::Install (part of
> > > ExtUtils::MakeMaker) [...]'s install() subroutine which
> > > later copies files from blib/ to $DESTDIR/$PREFIX/ which [...]
> > > looks like a hardcoded 0444 plus executable bit where necessary:

[snip]

> > > So IMHO it's not dh_strip_nondeterminism's fault, also because it
> > > perl's open() which indeed does bail out on trying to write to files
> > > with 444 (i.e. read-only) permissions (at least as unprivileged user).

[huge cut]

Whilst I conisder ExtUtils::MakeMaker's behaviour fairly weird (and
besides, if left alone it wouldn't be complian with Policy §10.9 -
probably that's hidden by dh_fixperms?), I don't think we need to do any
of the change you suggest in your mail.

I might be heavily downgrading the issue you found, and simply say that
File::StripNondeterminism::handlers::png is too eager in the open().
Amongst the various handlers, png and ar are the only to that uses +<
while opening the original file, but the png one has no reason to.  What
it does it a series of read()s to get data out, write it to a temporary
file, and then copy the data over the original file in some other way
(it uses File::Copy::copy).

I tried live patching strip-nd by chaging the
    open(my $fh, '+<', $filename)
to
    open(my $fh, '<', $filename)
and indeed I could get a build completely identical to the one done
without R³ and unpatched strip-nd (and the log confirms files are still
being processed by strip-nd.

So, I think that to handle this issue we should just drop that single
byte from strip-nd and consider it done.


This leaves the ar handler.  I don't think there are many (if any) perl
packages shipping ar files that aren't otherwise writable, but I believe
anybody with some perl knowledge could change the strip-nd ar handler to
use the same temporary file structure uesd by the other handlers as
well.

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20171028/fa110e5e/attachment.sig>