[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problems verifying signed github releases (Re: Q: uscan with GitHub)


On Sun, 2023-02-19 at 18:34:56 +0100, Jens Reyer wrote:
> [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.

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


Reply to: