[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.
Riccardo
[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.
Greets
jre
[3]The "alternative local workflow" described at
https://wiki.debian.org/Creating%20signed%20GitHub%20releases
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)