[b4] Sign gzipped tarball instead of .tar

[b4] Sign gzipped tarball instead of .tar

[foxboron]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

Yo!

Currently packaging up b4 for Arch Linux and encountered a slight issue with the
release tarballs for the project.

The siganture says it needs to be compared against the tarball of the project,
however the kernel.org and googlesource.com only allows one to download the
gzipped tarball. To recreat the release artifact one would need to clone and
create the archive to have anything to compare against.

This doesn't work that well since we preferably include the sources
declaratively and not work out a tarball from the source checkout during
packaging. This also has the effect of most distros packaging the release
straight from pypi or from git with no release authentication.

Could the gzipped release tarballs be signed instead? Another alternative would
be to sign the release tags of b4.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [tools] [b4] Sign gzipped tarball instead of .tar

[Konstantin Ryabitsev]

On Wed, Feb 17, 2021 at 02:43:33PM +0100, Morten Linderud wrote:
> Yo!
> 
> Currently packaging up b4 for Arch Linux and encountered a slight issue with the
> release tarballs for the project.
> 
> The siganture says it needs to be compared against the tarball of the project,
> however the kernel.org and googlesource.com only allows one to download the
> gzipped tarball. To recreat the release artifact one would need to clone and
> create the archive to have anything to compare against.

Or run:
xz -cd b4-0.6.2.tar.xz | gpg2 --verify b4-0.6.2.tar.sign -

You can get .xz archives here:
https://www.kernel.org/pub/software/devel/b4/

> This doesn't work that well since we preferably include the sources
> declaratively and not work out a tarball from the source checkout during
> packaging. This also has the effect of most distros packaging the release
> straight from pypi or from git with no release authentication.
> 
> Could the gzipped release tarballs be signed instead? Another alternative would
> be to sign the release tags of b4.

FYI, all software released on kernel.org provides a signature against the
uncompressed .tar archive. This is done to allow providing a single signature
file for multiple compressed versions (.gz, .xz) and allow for recompressing
things in the future with better algorithms or higher compression ratios.

Regards,
-K

Re: [tools] [b4] Sign gzipped tarball instead of .tar

[Morten Linderud]

[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]

On Wed, Feb 17, 2021 at 09:08:14AM -0500, Konstantin Ryabitsev wrote:
> On Wed, Feb 17, 2021 at 02:43:33PM +0100, Morten Linderud wrote:
> > Yo!
> > 
> > Currently packaging up b4 for Arch Linux and encountered a slight issue with the
> > release tarballs for the project.
> > 
> > The siganture says it needs to be compared against the tarball of the project,
> > however the kernel.org and googlesource.com only allows one to download the
> > gzipped tarball. To recreat the release artifact one would need to clone and
> > create the archive to have anything to compare against.
> 
> Or run:
> xz -cd b4-0.6.2.tar.xz | gpg2 --verify b4-0.6.2.tar.sign -
> 
> You can get .xz archives here:
> https://www.kernel.org/pub/software/devel/b4/
> 
> > This doesn't work that well since we preferably include the sources
> > declaratively and not work out a tarball from the source checkout during
> > packaging. This also has the effect of most distros packaging the release
> > straight from pypi or from git with no release authentication.
> > 
> > Could the gzipped release tarballs be signed instead? Another alternative would
> > be to sign the release tags of b4.
> 
> FYI, all software released on kernel.org provides a signature against the
> uncompressed .tar archive. This is done to allow providing a single signature
> file for multiple compressed versions (.gz, .xz) and allow for recompressing
> things in the future with better algorithms or higher compression ratios.

Ah well, I did a mistake! It turns out this is handled by pacman implicitly. I
didn't need to do anything and the issue is because I messed up the downloaded
files :) I had no clue this was even a thing.

I also found a bug as it doesn't handle zstd archives :)

> Regards,
> -K

Thanks for the fast reply and apologizes for the noise!

-- 
Morten Linderud
PGP: 9C02FF419FECBE16

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]