search

kiss-community / repo

KISS Linux - Unofficial Repositories, mirror of https://codeberg.org/kiss-community/repo
https://kisslinux.org
MIT License
39 stars 17 forks source link

proposal: use b3sum instead of sha256 in checksums file #100

Open echawk opened 1 year ago

echawk commented 1 year ago

b3sum is much faster than sha256, and is the default on carbs linux. As for implementations, I'd assume a preference for mcf's implementation. This has also been discussed previously in https://github.com/kiss-community/kiss/pull/39

apprehensions commented 1 year ago

Why BLAKE3 and not look at other hashing functions?

git-bruh commented 1 year ago

If we implement this, I suggest to add a b3sums file instead of checksum

dilyn-corner commented 1 year ago

Why? It's still a checksum

git-bruh commented 1 year ago

Why? It's still a checksum

The checksum name was suggested just because checksums would be treated as sha256 by old KISS versions so b3sums feels like a more appropriate name rather than choosing one just because the "correct" name is not available

aabacchus commented 1 year ago

This is feedback on kiss-community/kiss#72, but written here to keep the discussion in one place.

Given that the sh256 logic is still there, why not use the difference in names as an option: repo can use b3sums, but others can still use checksums without error until they are updated. Some generous repo maintainers could provide both files so that those who don't want to install an extra tool can choose their implementation.

On the other hand, but towards the same goal, the existing checksums file format could be changed - for example, so that the first line is the type ('sh256' or 'b3sum', or something else) or so that each line has a second field with the checksum type. Having two fields in each line would provide a way to distinguish "old" checksums from the new format.

ioraff commented 1 year ago

Given that the sh256 logic is still there, why not use the difference in names as an option: repo can use b3sums, but others can still use checksums without error until they are updated. Some generous repo maintainers could provide both files so that those who don't want to install an extra tool can choose their implementation.

The intention is for that logic to eventually be removed. I just want the transition to be less painful.

On the other hand, but towards the same goal, the existing checksums file format could be changed - for example, so that the first line is the type ('sh256' or 'b3sum', or something else) or so that each line has a second field with the checksum type. Having two fields in each line would provide a way to distinguish "old" checksums from the new format.

I feel like this just accomplishes the same thing in a more complicated (and still not backwards compatible) way.

git-bruh commented 1 year ago

https://codeberg.org/kiss-community/repo/issues/100