search

KnossosNET / Knossos.NET

Repository for the Knossos.NET launcher, currently in development.
GNU General Public License v3.0
23 stars 10 forks source link

Checksums of binary releases #28

Closed topas-rec closed 5 months ago

topas-rec commented 9 months ago

I am building an arch AUR binary package. It would be nice to have some checksums to verify. Could you please provide them?

Shivansps commented 9 months ago

What you would need?, something like a Knossos.NET-aarch64.AppImage (Bin) Knossos.NET-aarch64.AppImage.sha256 (checksum inside)

Linux_x64.tar.gz (compressed bin) Linux_x64.tar.gz.sha256 (checksum inside)

added to the releases?

notimaginative commented 9 months ago

Or a checksums.txt with the sha256 of all binary files in the release?

topas-rec commented 9 months ago

I guess a SHA256 of the Linux tar.gz would be enough.

I want to check how others are doing it and come back with more insights.

topas-rec commented 9 months ago

And I guess just the checksums as text would be enough. I've seen checksums as text in download pages. I don't know if checksum files would make it easier or better.

topas-rec commented 9 months ago

It seems there is an ongoing discussion about that at least for github. See https://github.com/orgs/community/discussions/23512 for details.

Two repos that do it in checksums.txt files are noted here: https://github.com/xonsh/xonsh/issues/4244

If i could chose, I would like to see the hash of at least the Linux_64.tar.gz as text on the release page and not in files. A checksum file doesn't help I think, since it could also be compromised during download.

Shivansps commented 9 months ago

On that regard my question would be if a checksum is actually needed for .tar.gz files considering both .tar.gz and .zip includes a built-in CRC32 checksum. The AppImage would certanly need it.

notimaginative commented 9 months ago

It would still be good to have in order to verify file integrity. Both .tar.gz and .zip will extract everything they can from a broken file. Being able to check the archive against a sha265 is a better way to test for a broken/partial download. And I believe AppImage has built in integrity checking.

A checksum isn't great as a security measure though. If the origin file is modified then it's likely the checksum file is modified, and that a checksum listed on the web page is likely modified too. A gpg signature would be a more appropriate way of determining if a file has been maliciously modified or not.

topas-rec commented 9 months ago

I plan to switch to a package built from a source release tarball. It seems also valid to sign commits and tags using pgp. They can be verified when checked out.

Shivansps commented 8 months ago

As of 0.2.0-RC8 a checksum file is generated along with the releases, i know this is not exactly what you asked, but it might help you.

topas-rec commented 7 months ago

Thank you!

Currently I am using the commit signing that your commits through github provide. I have to work around missing signed tags, so I get the commits for the tags.

Here is the AUR PCKGBUILD.

I read that signing in git (commits or tags) authenticates the committer (you use github webflow - it only authenticates your github account) and guarantees file integrity. That would be perfect and relatively easy.

Currently for me the best would be you would provide signed tags - if you can.

JohnAFernandez commented 6 months ago

I have been doing my best to sign the release tags for the past 3 releases. Could you see if I have been signing them correctly?

topas-rec commented 6 months ago

Oh edit: yes no, sorry I didn't realise that the tags itself were signed. Can you sign the latest 1.0.0 tag, too? This one seems not signed so far. I will then update directly to the latest version, hopefully using signed tags. Thanks.

JohnAFernandez commented 6 months ago

Ok, so the method I used to do the 1.0.0 release didn't seem to work. I verified that using the github website signs properly. (at least, afaict) So the next release should be signed.

I don't think I can go back and sign the last tag, though.

JohnAFernandez commented 5 months ago

Ok, if you see that creating the release through github as I just did for 1.1 does not sign properly as it seems to, please feel free to reopen this.