On Mon, Dec 11, 2017 at 2:11 PM, Jelle van der Waa <je...@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
