Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101339
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.178 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <20171211211157.d7lj5vibpaaka4ji@gmail.com>
References: <20171211211157.d7lj5vibpaaka4ji@gmail.com>
Date: Tue, 12 Dec 2017 14:12:47 -0700
Message-ID: <CAFMT4NoWuBiNrAu3VjmhjWc_DfoWQa3FfTFxSBwDiDDtkvi8VA@mail.gmail.com>
To: Jelle van der Waa <jelle@vdwaa.nl>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] Reproducible Builds Support
From: levim@php.net (Levi Morrison)

On Mon, Dec 11, 2017 at 2:11 PM, Jelle van der Waa <jelle@vdwaa.nl> wrote:
> Hi all,
>
> Debian, Arch Linux and other distro's are trying to get full
> reproducible builds. There are some issues in PHP's codebase which makes
> builds unreproducible. Reprodicuble builds are currently reproduced in
> Arch Linux by building PHP twice, and in two different env's, varying
> hostname, system time, etc. [1]
>
> Once issue is the PHP_BUILD_DATE, which makes the build
> non-reproducible. I've made a PR which uses SOURCE_DATE_EPOCH which is
> set in the reprodiculbe build env. This should keep the current
> functionality intact, while adding support for reproducible builds. [2]
> [3]

It looks good to me.

> Another issue is the php_uname functions which contains the
> hostname, since the hostname is varied per build this makes it
> non-reproducible. This is caused by the following line:
>
> configure.ac:PHP_UNAME=`uname -a | xargs` required in:
> ext/standard/info.c:            php_uname = PHP_UNAME;
>
> Which is there as fallback as the php.net documentation describes:
>
> "On some older UNIX platforms, it may not be able to determine the
> current OS information in which case it will revert to displaying the OS
> PHP was built on. This will only happen if your uname() library call
> either doesn't exist or doesn't work.".
>
> I would argue that this is strange unexpected behaviour, and maybe it
> should throw an exception instead? Or can it show only "Linux" as
> fallback? basically PHP_OS. Ideas?

I wouldn't throw an exception here. It seems PHP_OS is
under-documented; maybe PHP_OS_FAMILY is better:

> The operating system family PHP was built for. Either of 'Windows', 'BSD', 'Darwin', 'Solaris', 'Linux' or 'Unknown'. Available as of PHP 7.2.0.

However, I really don't think we should change this for already
released PHP versions. We should our maintainers how they feel about
changing it in a x.y.NEXT patch. My inclination is to do this for PHP
7.3 and beyond and accept that official PHP sources of earlier
versions will not produce reproducible builds.

> The last issue is phar.phar being non-reproducible of which I am not
> sure what the issue would be. I'm not sure how the binary data in the
> phar.phar is generated.

Phars are like `tars` that are also valid PHP files. This means there
are probably modification times, etc, set in there. Not sure what else
would need to be changed.