Bug#784335: libapache2-mod-perl2: please make the package build reproducible

[Niko Tyni]

On Wed, May 06, 2015 at 04:55:20PM +0200, gregor herrmann wrote:
> On Tue, 05 May 2015 16:22:02 +0200, Jérémy Bobbio wrote:
> Thanks for the bug report and patch.
> 
> For reference, here's the debbindiff:
> https://reproducible.debian.net/dbd/unstable/amd64/libapache2-mod-perl2_2.0.9~1624218-2.debbindiff.html

> > +libapache2-mod-perl2 (2.0.9~1624218-2.0~reproducible1) UNRELEASED; urgency=low
> > +
> > +  * Set PERL_HASH_SEED=0 when running configure to generate
> > +    identical code accross builds.
> > +
> > + -- Jérémy Bobbio <lunar at debian.org>  Tue, 05 May 2015 16:13:37 +0200
> > +

> >  override_dh_auto_configure:
> > -	dh_auto_configure -- \
> > +	PERL_HASH_SEED=0 dh_auto_configure -- \
> >  		INSTALLDIRS=vendor \
> >  		MP_TRACE=0 \
> >  		MP_USE_DSO=1 \

> I'm a bit wary here since
> - I don't really understand what this PERL_HASH_SEED variable does

It disables hash order randomization. From perlrun.pod:

    PERL_HASH_SEED
                (Since Perl 5.8.1, new semantics in Perl 5.18.0) Used to
                override the randomization of Perl's internal hash function.
                The value is expressed in hexadecimal, and may include a
                leading 0x. Truncated patterns are treated as though they are
                suffixed with sufficient 0's as required.

                If the option is provided, and "PERL_PERTURB_KEYS" is NOT set,
                then a value of '0' implies "PERL_PERTURB_KEYS=0" and any
                other value implies "PERL_PERTURB_KEYS=2".

                PLEASE NOTE: The hash seed is sensitive information. Hashes
                are randomized to protect against local and remote attacks
                against Perl code. By manually setting a seed, this protection
                may be partially or completely lost.

                See "Algorithmic Complexity Attacks" in perlsec,
                "PERL_PERTURB_KEYS", and "PERL_HASH_SEED_DEBUG" for more
                information.

ISTR we've used PERL_HASH_SEED=0 in the past as a last resort for running
test suites that rely on hash ordering and aren't easily fixable.

In this case, I assume the configure step writes out quite a few makefiles
and the like, and the generating code would otherwise need to be patched
to sort hash keys.

I certainly hope setting PERL_HASH_SEED=0 in the configure step doesn't
carry over to the built embedded Perl interpreter. If it did, that would
introduce a definite security problem. This seems unlikely to me, however.
-- 
Niko Tyni   ntyni at debian.org