Issue 38727: setup.py sdist --format=gztar should use (equivalent of) `gzip -n`

classification

Title:	setup.py sdist --format=gztar should use (equivalent of) `gzip -n`
Type:		Stage:
Components:	Distutils	Versions:

process

Status:	open	Resolution:
Dependencies:		Superseder:
Assigned To:		Nosy List:	dstufft, eric.araujo, zwol
Priority:	normal	Keywords:

Created on 2019-11-06 20:14 by zwol, last changed 2019-11-06 20:14 by zwol.

Messages (1)
msg356152 - (view)	Author: Zack Weinberg (zwol) *	Date: 2019-11-06 20:14
Recent versions of the gzip command-line utility have an option `-n` which causes it to omit the FNAME field of the gzip file header, and write out the MTIME field as zero. Both of these properties are desirable when constructing reproducible build artifacts (see https://reproducible-builds.org/ ). An sdist tarball is a build artifact and it should be created as reproducibly as possible. In particular, --format=gztar should behave as-if `gzip -n` were in use. (The stdlib's gzip module can produce output equivalent to what gzip -n does, but this is not currently documented nor is it accessible via `tarfile`. Both of those should be easy fixes. See bug 38725 and bug 38726.)

msg356152 - (view)

Author: Zack Weinberg (zwol) *

Date: 2019-11-06 20:14

Recent versions of the gzip command-line utility have an option `-n` which causes it to omit the FNAME field of the gzip file header, and write out the MTIME field as zero.  Both of these properties are desirable when constructing reproducible build artifacts (see https://reproducible-builds.org/ ).

An sdist tarball is a build artifact and it should be created as reproducibly as possible.  In particular, --format=gztar should behave as-if `gzip -n` were in use.  (The stdlib's gzip module can produce output equivalent to what gzip -n does, but this is not currently documented nor is it accessible via `tarfile`.  Both of those should be easy fixes.  See bug 38725 and bug 38726.)

History
Date	User	Action	Args
2019-11-06 20:14:38	zwol	create