Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101354
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain vdwaa.nl from 74.125.82.42 cause and error)
Date: Thu, 14 Dec 2017 10:02:10 +0100
To: Levi Morrison <levim@php.net>
Cc: PHP Internals <internals@lists.php.net>
Message-ID: <20171214090209.7in22vsbrjaxvsxe@gmail.com>
References:<20171211211157.d7lj5vibpaaka4ji@gmail.com>
 <CAFMT4NoWuBiNrAu3VjmhjWc_DfoWQa3FfTFxSBwDiDDtkvi8VA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:<CAFMT4NoWuBiNrAu3VjmhjWc_DfoWQa3FfTFxSBwDiDDtkvi8VA@mail.gmail.com>
User-Agent: NeoMutt/20171208
Subject: Re: [PHP-DEV] [RFC] Reproducible Builds Support
From: jelle@vdwaa.nl (Jelle van der Waa)

On 12/12/17 at 02:12pm, Levi Morrison wrote:
> 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:

PHP_OS and PHP_OS_FAMILY is a strange difference indeed. I'll have to do
some further digging.

> 
> > 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.

Indeed, as an Arch Linux developer I'm fine with these changes adding up
in the next release and no backporting.
 
> > 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.

Thanks for the information, I'll see if I can do some more digging.

-- 
Jelle van der Waa