[RFC] Reproducible Builds Support View as Markdown

Hi!

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]

SOURCE_DATE_EPOCH (or any other variable) looks like a good way to make
it predictable.

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;

I think the best solution here would be to have another variable to
override this.

The issue with this approach would be that every distribution has to set
this variable. I know it's the same with SOURCE_DATE_EPOCH, but that is
well established.

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?

If those old systems run PHP and need uname, changing stuff there is
probably harder and more expensive than on other systems. With this in
mind, I'd rather not mess with it, especially for a purpose that can
easily be achieved without it.

Hmmm true, but the fallback being the hostname where PHP was build on
seems a little bit odd, doesn't it?

--
Jelle van der Waa

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