Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
echawk opened this issue Sep 7, 2022 · 7 comments
Open

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

echawk opened this issue Sep 7, 2022 · 7 comments
Labels

Comments

@echawk
Copy link
Member

echawk commented Sep 7, 2022

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 kiss-community/kiss#39

@ioraff ioraff added the proposal label Sep 7, 2022
@echawk echawk changed the title proprosal: use b3sum instead of sha256 in checksums file proposal: use b3sum instead of sha256 in checksums file Sep 8, 2022
@apprehensions
Copy link

Why BLAKE3 and not look at other hashing functions?

@git-bruh
Copy link
Member

git-bruh commented Sep 8, 2022

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

@dilyn-corner
Copy link
Member

Why? It's still a checksum

@git-bruh
Copy link
Member

git-bruh commented Sep 9, 2022

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
Copy link
Member

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
Copy link
Member

ioraff commented Sep 14, 2022

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
Copy link
Member

@kiss-community kiss-community locked and limited conversation to collaborators Sep 27, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

6 participants