Re: Problems verifying signed github releases (Re: Q: uscan with GitHub)
* 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
Reply to: