* Guillem Jover <guil...@debian.org> [2023-02-19 20:50]: > > My upstream creates a tarball with git-archive, creates a signature and > > uploads it (as described in the wiki[3]). This used to work to verify > > the github-created tarball, but fails now - while creating my own > > tarball like upstream and verifying it with upstream's signature works. > > > > The uncompressed .tar files are identical (same hashsum), just the tar.gz > > differ. Does anyone know why, and how to fix it? I tried non-default > > compression levels for gzip with git-archive, but that didn't help to get an > > identical tar.gz like the one from github. > > > > I'd like to avoid having my upstream downloading the github-created > > tarball, verify&sign it and then upload this signature. > > I assume you (or whatever service or tool is failing the verification > while creating a local tarball) might be seeing issues with git having > switched implementation for gzip, and a mismatch with the implementation > being used in either side. Perhaps try to set git's > tar.tar.gz.command="gzip -c" (or/and «tgz» instead of «tar.gz») to use > the external command instead of the internal implementation? Or perhaps > you are using an old git that defaults to the external gzip but upstream > uses the internal one?
I was going to suggest that might be the issue, but you were faster :) I do have some relevant links: https://reproducible-builds.org/reports/2023-01/#news https://lists.reproducible-builds.org/pipermail/rb-general/2022-October/002709.html https://lists.reproducible-builds.org/pipermail/rb-general/2022-October/002710.html > (There was a recent LWN article covering this, see > https://lwn.net/Articles/921787/.) That seems to be subscribers-only :( - FC