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

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

[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.]

> On Tue, Oct 11, 2022 at 10:23 AM Stephan Lachnit <stephanlachnit@debian.org> wrote:
>> On Sun, Oct 9, 2022 at 7:06 PM Volans <volans.ubuntu@gmail.com> wrote:
For releases I use something like (w/o signatures): ``` version=4 opts="searchmode=plain,\ filenamemangle=s%v?@ANY_VERSION@%@PACKAGE@-$1.tar.gz%" \ https://api.github.com/repos/<user>/<project>/releases?per_page=100 \ https://api.github.com/repos/[^/]+/[^/]+/tarball/v?@ANY_VERSION@ ```
To add some additional burden I noticed that the archive downloaded from the API [1] is different from the one downloaded from the browser [2] because they have a different top-level directory name, while the API one has: {OWNER}-{REPO}-{REF_SHA1}/ where REF_SHA1 is the SHA1 of refs/tags/{TAG_NAME}, the browser one has: {OWNER}-{VERSION}/ where, at least in my case, VERSION is the tag name without the leading 'v'. For a tag name of 'v0.2.0' I get 'gjson-py-0.2.0.tar.gz' that extracted creates 'gjson-py-0.2.0/' (note the lack of 'v' in the names).

Because of the two different directory structures, the tar.gz files are different so any md5 or gpg signature verification made on one would fail with the other, adding additional confusion or complexity.
For now I'll probably upload to the release page the signatures of
both files, but this is definitely suboptimal.


[1] https://api.github.com/repos/{OWNER}/{REPO}/tarball/{RELEASE}
[2] https://codeload.github.com/{OWNER}/{REPO}/tar.gz/refs/tags/{RELEASE}

I use the mentioned tarball from the browser release page, but it still fails to verify with upstream's locally created signature:

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.


[3]The "alternative local workflow" described at

Reply to: