phar.phar from php 8.3.26 is not reproducible

[apteryks]

Description

The following command:

guix build php --no-grafts --check

Allowed discovering of the following non-reproducibility:

$ diffoscope /gnu/store/5l113d06j2j3jnf6bvzhhd9iny7ki2m6-php-8.3.26{,-check}
--- /gnu/store/5l113d06j2j3jnf6bvzhhd9iny7ki2m6-php-8.3.26
+++ /gnu/store/5l113d06j2j3jnf6bvzhhd9iny7ki2m6-php-8.3.26-check
├── /gnu/store/lzf20vxz8rq5d1akv907c1g3a0mq2z01-coreutils-9.1/bin/stat {}
│ @@ -1,8 +1,8 @@
│  
│    Size: 62        	Blocks: 0          IO Block: 4096   directory
│  Device: 0,26	Links: 1
│ -Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
│ +Access: (0555/dr-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
│  
│  Modify: 1970-01-01 00:00:01.000000000 +0000
│   --- /gnu/store/5l113d06j2j3jnf6bvzhhd9iny7ki2m6-php-8.3.26/bin
├── +++ /gnu/store/5l113d06j2j3jnf6bvzhhd9iny7ki2m6-php-8.3.26-check/bin
│ │   --- /gnu/store/5l113d06j2j3jnf6bvzhhd9iny7ki2m6-php-8.3.26/bin/phar.phar
│ ├── +++ /gnu/store/5l113d06j2j3jnf6bvzhhd9iny7ki2m6-php-8.3.26-check/bin/phar.phar
│ │ @@ -67,30 +67,30 @@
│ │  00000420: 293b 0a0a 6e65 7720 5068 6172 436f 6d6d  );..new PharComm
│ │  00000430: 616e 6428 2461 7267 632c 2024 6172 6776  and($argc, $argv
│ │  00000440: 293b 0a0a 5f5f 4841 4c54 5f43 4f4d 5049  );..__HALT_COMPI
│ │  00000450: 4c45 5228 293b 203f 3e0d 0a36 0100 0006  LER(); ?>..6....
│ │  00000460: 0000 0011 0000 0001 000b 0000 0070 6861  .............pha
│ │  00000470: 7263 6f6d 6d61 6e64 0000 0000 0f00 0000  rcommand........
│ │  00000480: 7068 6172 636f 6d6d 616e 642e 696e 63f8  pharcommand.inc.
│ │ +00000490: c200 0079 42db 68aa 2500 001f 1442 43a4  ...yB.h.%....BC.
│ │ -00000490: c200 00e9 3fdb 68aa 2500 001f 1442 43a4  ....?.h.%....BC.
│ │  000004a0: 1100 0000 0000 0008 0000 0070 6861 722e  ...........phar.
│ │ +000004b0: 696e 63a3 0300 0079 42db 6831 0100 0083  inc....yB.h1....
│ │ -000004b0: 696e 63a3 0300 00e9 3fdb 6831 0100 0083  inc.....?.h1....
│ │  000004c0: 3b31 48a4 1100 0000 0000 0019 0000 0069  ;1H............i
│ │  000004d0: 6e76 6572 7465 6472 6567 6578 6974 6572  nvertedregexiter
│ │ +000004e0: 6174 6f72 2e69 6e63 d701 0000 7942 db68  ator.inc....yB.h
│ │ -000004e0: 6174 6f72 2e69 6e63 d701 0000 e93f db68  ator.inc.....?.h
│ │  000004f0: d500 0000 8c58 669a a411 0000 0000 0000  .....Xf.........
│ │  00000500: 1900 0000 6469 7265 6374 6f72 7974 7265  ....directorytre
│ │  00000510: 6569 7465 7261 746f 722e 696e 63a1 0500  eiterator.inc...
│ │ +00000520: 0079 42db 685d 0200 00b6 a6e5 1da4 1100  .yB.h]..........
│ │ -00000520: 00e9 3fdb 685d 0200 00b6 a6e5 1da4 1100  ..?.h]..........
│ │  00000530: 0000 0000 001a 0000 0064 6972 6563 746f  .........directo
│ │  00000540: 7279 6772 6170 6869 7465 7261 746f 722e  rygraphiterator.
│ │ +00000550: 696e 6344 0300 0079 42db 6870 0100 00de  incD...yB.hp....
│ │ -00000550: 696e 6344 0300 00e9 3fdb 6870 0100 00de  incD....?.hp....
│ │  00000560: 2a3d 44a4 1100 0000 0000 000e 0000 0063  *=D............c
│ │  00000570: 6c69 636f 6d6d 616e 642e 696e 63ea 2a00  licommand.inc.*.
│ │ +00000580: 0079 42db 6888 0a00 00f9 22bb dba4 1100  .yB.h.....".....
│ │ -00000580: 00e9 3fdb 6888 0a00 00f9 22bb dba4 1100  ..?.h.....".....
│ │  00000590: 0000 0000 00ed 3d6b 77db 36b2 dff3 2b90  ......=kw.6...+.
│ │  000005a0: acbb 941a 59b6 b39b b69b d44e 9dd4 6d73  ....Y......N..ms
│ │  000005b0: 4e1e 3e71 dade d6c9 6a29 8992 b9a6 482e  N.>q....j)....H.
│ │  000005c0: 4939 76da fcf7 3b33 7810 0401 3e2c 27db  I9v...;3x...>,'.
│ │  000005d0: de73 754e 1b59 0406 83c1 bc31 00bf 7e94  .suN.Y.....1..~.
│ │  000005e0: 9ea5 b76e ed7c fef9 2df6 39fb 6611 4601  ...n.|..-.9.f.F.
│ │  000005f0: 4bcf fc6c 96ac 567e 3c1f 87f1 8c1e 84f1  K..l..V~<.......
│ │ @@ -947,10 +947,10 @@
│ │  00003b20: 3532 9f44 abfb 2677 8bd3 53aa 7bef aa6c  52.D..&w..S.{..l
│ │  00003b30: cc46 0fdd 55a2 db5c b97f b4d4 e4cc 8dad  .F..U..\........
│ │  00003b40: 8377 7b62 7072 aca8 1a73 44ce 0bd6 91e1  .w{bpr...sD.....
│ │  00003b50: fe67 3ca8 438d c3fb 1a7c a99c 840c 341c  .g<.C....|....4.
│ │  00003b60: b706 b332 f481 13b4 4ef9 1d63 f43b 2c48  ...2....N..c.;,H
│ │  00003b70: 84de d328 a6b7 f50f 3045 636c eeac f66e  ...(....0Ecl...n
│ │  00003b80: ec7d 3951 8a29 0f3c 6550 99a7 9d56 3934  .}9Q.).<eP...V94
│ │ +00003b90: fdee e508 f8f8 657e f45f 527f 9d9b 61e3  ......e~._R...a.
│ │ +00003ba0: c7ba 658b 3582 354b a78f d009 b6d3 0200  ..e.5.5K........
│ │ -00003b90: fdee e508 f8f8 657e f45f e32f 5902 51a7  ......e~._./Y.Q.
│ │ -00003ba0: f8c5 0422 d3c4 b5ba 31cc 2c34 76c3 0200  ..."....1.,4v...
│ │  00003bb0: 0000 4742 4d42                           ..GBMB

The build should be reproducible. That's when made in Guix with all the usual precautions taken (SOURCE_DATE_EPOCH, etc.).

PHP Version

8.3.26.

Operating System

Guix

[apteryks]

This seems a known issue? https://github.com/box-project/box/blob/main/doc/reproducible-builds.md

[nielsdos]

Without looking into detail yet, I can already tell that phars include timestamps, including of the creation of the phar itself. So they're not reproducible right now.

[apteryks]

It'd be nice if the timestamps honored at least SOURCE_EPOCH_DATE, the common solution to that (this is an environment variable that gets set to some epoch value, e.g. 1, and any time a date is requested from software, it uses that (more info: https://reproducible-builds.org/docs/source-date-epoch/).

[NattyNarwhal]

Reading the phar source, it seems phar honours the existing timestamps if it builds a phar from a tarball/zip file. Otherwise, it just calls time(NULL) when making entries, so the phar API might need to be changed to allow for changing the timestamp for a file.

[NattyNarwhal]

Thinking a little more, I also realize that:

• It could just stat the files (for real files) and use that timestamp, so changing the API may not be necessary.
• ...but also, the timestamp is 32-bit, and I don't think phar really exposes the timestamps beyond for the PHP VFS stuff (so you can stat it). Perhaps it might be best to deprecate the timestamp and set it to 0, and have a timestamp in the metadata field (since that's extensible and doesn't mean changing the format) instead if we really care about it?

[NattyNarwhal]

FWIW, this doesn't fail any ext/phar tests:

diff --git a/ext/phar/phar.c b/ext/phar/phar.c
index 5a5012adbf1..9ddac71e492 100644
--- a/ext/phar/phar.c
+++ b/ext/phar/phar.c
@@ -2973,7 +2973,7 @@ void phar_flush_ex(phar_archive_data *phar, zend_string *user_stub, bool is_defa
 			4: metadata-len
 			+: metadata
 		*/
-		mytime = time(NULL);
+		mytime = 0;
 		phar_set_32(entry_buffer, entry->uncompressed_filesize);
 		phar_set_32(entry_buffer+4, mytime);
 		phar_set_32(entry_buffer+8, entry->compressed_filesize);
diff --git a/ext/phar/stream.c b/ext/phar/stream.c
index 2317c07d641..299084af32c 100644
--- a/ext/phar/stream.c
+++ b/ext/phar/stream.c
@@ -470,7 +470,7 @@ static int phar_stream_flush(php_stream *stream) /* {{{ */
 	phar_entry_data *data = (phar_entry_data *) stream->abstract;
 
 	if (data->internal_file->is_modified) {
-		data->internal_file->timestamp = time(0);
+		data->internal_file->timestamp = 0;
 		phar_flush(data->phar, &error);
 		if (error) {
 			php_stream_wrapper_log_error(stream->wrapper, REPORT_ERRORS, "%s", error);
diff --git a/ext/phar/tar.c b/ext/phar/tar.c
index d8c412b5a9b..9c5603613f4 100644
--- a/ext/phar/tar.c
+++ b/ext/phar/tar.c
@@ -977,7 +977,7 @@ void phar_tar_flush(phar_archive_data *phar, zend_string *user_stub, bool is_def
 	char *buf, *signature, sigbuf[8];
 
 	entry.flags = PHAR_ENT_PERM_DEF_FILE;
-	entry.timestamp = time(NULL);
+	entry.timestamp = 0;
 	entry.is_modified = 1;
 	entry.is_crc_checked = 1;
 	entry.is_tar = 1;
diff --git a/ext/phar/util.c b/ext/phar/util.c
index aa30515eff6..ea4e9953945 100644
--- a/ext/phar/util.c
+++ b/ext/phar/util.c
@@ -700,7 +700,7 @@ phar_entry_data *phar_get_or_create_entry_data(char *fname, size_t fname_len, ch
 
 	phar_add_virtual_dirs(phar, path, path_len);
 	etemp.is_modified = 1;
-	etemp.timestamp = time(0);
+	etemp.timestamp = 0;
 	etemp.is_crc_checked = 1;
 	etemp.phar = phar;
 	etemp.filename = zend_string_init(path, path_len, false);
diff --git a/ext/phar/zip.c b/ext/phar/zip.c
index a836d52d25d..e68abd355fb 100644
--- a/ext/phar/zip.c
+++ b/ext/phar/zip.c
@@ -158,7 +158,7 @@ static time_t phar_zip_d2u_time(const char *cdtime, const char *cddate) /* {{{ *
 	struct tm *tm, tmbuf;
 	time_t now;
 
-	now = time(NULL);
+	now = 0;
 	tm = php_localtime_r(&now, &tmbuf);
 
 	tm->tm_year = ((ddate>>9)&127) + 1980 - 1900;
@@ -1273,7 +1273,7 @@ void phar_zip_flush(phar_archive_data *phar, zend_string *user_stub, bool is_def
 
 	pass.error = &temperr;
 	entry.flags = PHAR_ENT_PERM_DEF_FILE;
-	entry.timestamp = time(NULL);
+	entry.timestamp = 0;
 	entry.is_modified = 1;
 	entry.is_zip = true;
 	entry.phar = phar;

[thg2k]

+1 from me, builds should be reproducible.

I always have to monkey-patch created phar files to make them reproducible in my projects.

It would be about nice if the phar API allowed to set an explicit timestamp, then the build system could use that API to enforce SOURCE_DATE_EPOCH

[nielsdos]

Vaguely related to #14143