[Reproducible-builds] Bug#802057: Bug#802057: libfile-stripnondeterminism-perl: fails with png file on armhf ("Negative length")

[Niko Tyni]

On Sat, Oct 17, 2015 at 01:37:30PM +0200, Roland Rosenfeld wrote:
> Package: libfile-stripnondeterminism-perl
> Version: 0.012-1
> Severity: normal
 
> there seems to be a bug in the png handler of stripnondeterminism,
> when run on armhf.
> When running dh_strip_nondetermism on a simple PNG file from the xfig
> documentation
> https://sources.debian.net/data/main/x/xfig/1:3.2.5.c-3/Doc/html/images/symbol-chars-upper.png
> I get the following result on armhf:
> 
> dh_strip_nondeterminism: ./symbol-chars-upper.png: Negative length at /home/roland/perllib/File/StripNondeterminism/handlers/png.pm line 66.

Interesting. 

The image seems to have another full PNG structure after the IEND chunk,
at offset 17958. The code just reads PNG chunks as long as there's data
available, getting the repeated PNG magic number (89 50 4e 47) as the
length of the next chunk. This is obviously not going to work.

The difference between amd64 and armhf is that read() lengths over 2**31
such as 0x89504e47 get treated as negative, as seen with
 echo foo | perl -e 'print read(\*STDIN, $foo, 1 << 31)'
which prints "Negative length" on armhf.

The documentation of the Perl read() call mentions fread(3), which
takes a size_t argument, so any signedness would seem inappropriate
(and nonsensical) here. So this may be a bug in perl.

Anyway, the immediate fix would be to have the PNG handler stop processing
at the first IEND chunk.
-- 
Niko Tyni   ntyni at debian.org