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?
(There was a recent LWN article covering this, see https://lwn.net/Articles/921787/.)
[This is a followup to the thread "Q: uscan with GitHub" at https://lists.debian.org/debian-devel/2022/10/msg00313.html. I manually set in-reply-to, but am not sure if it'll work.]
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.
* Guillem Jover <guillem@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
(There was a recent LWN article covering this, see >>https://lwn.net/Articles/921787/.)
That seems to be subscribers-only :(
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 546 |
Nodes: | 16 (2 / 14) |
Uptime: | 38:47:49 |
Calls: | 10,392 |
Files: | 14,064 |
Messages: | 6,417,182 |