Tuf: Verifiably reproducible build artefacts

[joshuagl]

Description of issue or feature request:

We can give users of our release artefacts (tarballs and wheels) greater confidence in the integrity of the artefacts and our development processes if they can verify that the artefacts we produced correspond to the signed tagged source code for the release.

We can achieve this through implementing reproducible builds.

Current behavior:

Tarball (sdist) and wheels (bdist_wheel) generated for a release __are not__ verifiably reproducible.

$ diff dist-a dist-b
Binary files dist-a/tuf-0.16.0-py2.py3-none-any.whl and dist-b/tuf-0.16.0-py2.py3-none-any.whl differ
Binary files dist-a/tuf-0.16.0.tar.gz and dist-b/tuf-0.16.0.tar.gz differ

Expected behavior:

Tarball (sdist) and wheels (bdist_wheel) generated for a release __are__ verifiably reproducible.

[joshuagl]

Ensuring SOURCE_DATE_EPOCH is set (i.e. this patch) enables us to create verifiably reproducible wheels, but the tarball (sdist) is still not verifiably reproducible.

$ diff dist-r-a dist-r-b
Binary files dist-r-a/tuf-0.16.0.tar.gz and dist-b-r/tuf-0.16.0.tar.gz differ

[joshuagl]

Note: I tried this on macOS and Fedora 33. I don't think the sdist being non-deterministic is host tool related.

[mnm678]

tar isn't deterministic by default, do they still differ when generated with --mtime?

[joshuagl]

Quite right, thanks for the link! Our sdist tarballs are generated by setuptools, which (so far as I could tell in the relatively brief time I spent looking today) has no option to specify mtime.

It's possible we just have to brute force this; unpack and re-pack the tarball with --mtime, use strip-nondeterminism, or similar.

I intend to spend some more time on this in the next couple of weeks, unless someone gets to it first.

[sethmlarson]

Hello! Dropping in to say it'd be nice if these techniques could be made available to the broader Python community somehow.