This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Allow setting timestamp in gzip-compressed tarfiles
Type: enhancement Stage:
Components: Library (Lib) Versions: Python 3.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: FFY00, jonash, maarten, martin.panter, randombit
Priority: normal Keywords:

Created on 2017-09-20 05:11 by randombit, last changed 2022-04-11 14:58 by admin.

Messages (5)
msg302590 - (view) Author: Jack Lloyd (randombit) Date: 2017-09-20 05:11
Context: I have a script which checks out a software release (tagged git revision) and builds an archive to distribute to end users. One goal of this script is that the archive is reproducible, ie if the script is run twice (at different times, on different machines, by different people) it produces bit-for-bit identical output, and thus also has the same SHA-256 hash.

Mostly this works great, using the TarInfo feature of tarfile.py to set the uid/gid/mtime to fixed values. Except I also want to compress the archive, and tarfile calls time.time() to find out the timestamp that will be embedded in the gzip header. This breaks my carefully deterministic output.

I would like it if tarfile accepted an additional keyword that allowed overriding the time value for the gzip header. As it is I just hack around it with

def null_time():
    return 0
time.time = null_time

which does work but is also horrible.

Alternately, tarfile could just always set the timestamp header to 0 and avoid having its output depend on the current clock. I doubt anyone would notice.

The script in question is here 
https://github.com/randombit/botan/blob/master/src/scripts/dist.py

My script uses Python2 for various reasons, but it seems the same problem affects even the tarfile.py in latest Python3. I would be willing to try writing a patch for this, if anything along these lines might be accepted.

Thanks.
msg305915 - (view) Author: Jonas H. (jonash) * Date: 2017-11-08 22:32
This affects me too.
msg306065 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2017-11-10 23:46
Perhaps you can compress the tar file using the “gzip.GzipFile” class. It accepts a custom “mtime” parameter (see Issue 4272, added in 2.7 and 3.1+):

>>> gztar = BytesIO()
>>> tar = GzipFile(fileobj=gztar, mode="w", mtime=0)
>>> tarfile.open(fileobj=tar, mode="w|").close()
>>> tar.close()
>>> gztar.getvalue().hex()
'1f8b08000000000002ffedc1010d000000c2a0f74f6d0e37a00000000000000000008037039ade1d2700280000'

However, “tarfile.open” accepts a “compresslevel” argument for two of the compressors, so you could argue it is okay to add another argument to pass to the gzip compressor.
msg375849 - (view) Author: Maarten (maarten) * Date: 2020-08-24 15:14
I have the same issue.
The timestamp is inserted here:
https://github.com/python/cpython/blob/802726acf6048338394a6a4750835c2cdd6a947b/Lib/tarfile.py#L419-L420

Because I noticed the timestamp was not included in the timestamp,
I could zero it by doing:
```
with open(gzipped_tarball,"r+b") as f:
    f.seek(4, 0)
    f.write(b"\x00\x00\x00\x00")
```
msg375850 - (view) Author: Maarten (maarten) * Date: 2020-08-24 15:22
My previous comment should have contained:

Because I noticed the timestamp was not included in the CRC,
...
History
Date User Action Args
2022-04-11 14:58:52adminsetgithub: 75707
2021-05-04 00:32:57FFY00setnosy: + FFY00
2020-08-24 15:22:17maartensetmessages: + msg375850
2020-08-24 15:14:18maartensetnosy: + maarten
messages: + msg375849
2017-11-10 23:46:22martin.pantersetnosy: + martin.panter
messages: + msg306065
2017-11-08 22:32:41jonashsetnosy: + jonash
messages: + msg305915
2017-09-20 05:11:11randombitcreate