release archives improvement

[532910]

1. linux archives should be tar.gz (or may be bz2 or xz) not zip. May be same for *bsd.
2. version should be included in the filename browserpass-linux64.zip -> browserpass-linux64-3.0.3.zip
3. archive should contain folder, not multiple files

[maximbaz]

1. It's a matter of personal preference, unzip exists on Linux, and bsdtar is able to unpack zip files (bsdtar -vxf *.zip -C mydir) - I went for one archive for all platforms for consistency. Unless there are particular reasons why zip is an awful choice?
2. Agreed, I see benefits 👍
3. I think it's another personal preference, personally I don't like enforced nested folders in archives, if you want you can always use unzip *.zip -d mydir.

[532910]

1. unzip should be installed separately; tar exists almost everywhere; linux kernel goes in tar.xz and tar.gz (for compatibility)

2. Put files directly in archive, without folder, has only one reason. when it's a system packages and you extract it from the /thus upgrading the system. In the archives for people, it's handful to make one folder. I, like many other people, extract all archives with just tar xvf (or unzip) and some archives creates a lot of "garbage" that I should remove, and extract it again, into specific folder.

[maximbaz]

Given that both points are personal preference, I won't change this right now, this format and layout of the archive has been used for the past years with no issues.

By the way, highly recommend these zsh helpers: unarchive, archive and lsarchive - I don't remember when I used unzip or tar xvf directly last time, these helpers handle every popular archive format automatically, and they also take care of grouping the unarchived files in a separate folder 😉

[erayd]

For what it's worth, I actually think we should change this. Tar with a single folder at the top level is a very longstanding convention for Linux packaging, and it's what people expect - so IMO we should adhere to it. It's not just a matter of personal preference.

Additionally, unzip is not installed by default on many distros, and even where it's available, a large number of people won't create a new folder just to extract into. Having an archive unexpectedly crap random files all over $PWD is exceedingly annoying.

[maximbaz]

I don't completely agree, but I don't really have a strong opinion here, so let's make you happy: #40

.tar.xz ok? or .tar.gz is preferable?

[532910]

I think gz as the difference is only .3M (for 3.0.3 release). (Really I love xz, bug gz is more common.)

[maximbaz]

.tar.gz it is then

[532910]

yes

[532910]

Source code and signature should be named browserpass-native-3.0.4 not just 3.0.4

[maximbaz]

Source code archives are generated by Github directly and I don't have control over them:

That's why I name the signature file 3.0.4.tar.gz.sig so that it matches the archive file name.

[532910]

https://github.com/browserpass/browserpass-native/archive/3.0.4.zip
302 ->
https://codeload.github.com/browserpass/browserpass-native/zip/3.0.4
Content-Disposition: attachment; filename=browserpass-native-3.0.4.zip

So the file will be saved as browserpass-native-3.0.4.zip

signature filename should be updated

[maximbaz]

Hm you are right, I confirm by actually downloading the file :) Nicely spotted

[maximbaz]

By the way, if you are curious, I'm only providing a signature for .tar.gz and not .zip because the former is reproducible, i.e. I can run the command below and I'll get exactly the same archive as Github will generate, with identical hashsum:

git archive -o dist/browserpass-native-$(VERSION).tar.gz --format tar.gz --prefix=browserpass-native-$(VERSION)/ $(VERSION)

However according to my tests .zip archive is not reproducible, i.e. running the command below generates an archive with different hashsum, so my signature will be invalid for a file that Github creates:

git archive -o dist/browserpass-native-$(VERSION).zip --format zip --prefix=browserpass-native-$(VERSION)/ $(VERSION)

If you know how to fix this reproducibility issue for .zip, let me know and I'll be providing a signature for it too.

[532910]

1. Is it possible to generate source archives manually, not via github?

2. Could you make signature armored?

[532910]

gpg --verify works well for armored files

[maximbaz]

1. Yes, but it's not possible to prevent Github from attaching their source archives, don't want to have two different but identical archives in a release, to avoid confusion 🙂

2. Sure, but is there any benefit in using armored? You will be downloading the files anyway, not copy-pasting.

[532910]

is there any benefit in using armored?

1. It's user readable.
2. linux does this: https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/linux-5.0.1.tar.sign
3. for your sig file says "data", for linux's sign file says "PGP signature"

[532910]

same as browserpass/browserpass-extension#82:
what about debian-style naming: words in package name are hyphen-divided, version and architecture are underscore-divided:
http://ftp.us.debian.org/debian/pool/main/b/base-passwd/base-passwd_3.5.46_amd64.deb

[maximbaz]

okay you convinced me to use armored signatures, after all linux is all about text-based configs, so let's use text-based signatures, not some binary format 😉