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

2.0.14 sha files don't match eget spec #3486

Open
gdevenyi opened this issue Sep 28, 2024 · 4 comments
Open

2.0.14 sha files don't match eget spec #3486

gdevenyi opened this issue Sep 28, 2024 · 4 comments

Comments

@gdevenyi
Copy link

Description of the problem or steps to reproduce

The release download sha file naming don't match the spec expected by eget

If Eget downloads an asset called xxx and there also exists an asset called xxx.sha256 or xxx.sha256sum, Eget will automatically verify that the SHA-256 checksum of the downloaded asset matches the one contained in that file, and abort installation if a mismatch occurs.

https://github.com/zyedidia/eget#usage

@JoeKar
Copy link
Collaborator

JoeKar commented Sep 28, 2024

Is it just about the fact, that the *.sha files aren't named *.sha256?
eget only has a sha256 (--sha256 and --verify-sha256) option/support. Will it receive options for sha384 or sha512?

Yes I know, wrong person to address.
But shasum itself is capable of checking the provided hash by itself:

$ shasum -c micro-2.0.14-linux64.tar.gz.sha 
micro-2.0.14-linux64.tar.gz: OK

Honestly spoken the hash can be identified by its length, thus it's more or less superfluous to invoke a specific command or expect a specific sha# file extension.

@zyedidia Now I had to realize that eget is from you. 😅
From my perspective eget.go#L67 can be generalized by adding a further || a == asset+".sha" or directly a more smart regex like sha([0-9]{3})? or sha(224|256|384|512)?, verify.go#L5 to use the crypto/sha512 dependency (compatible from sha224..sha512) and to rename the sha256 function/identifiers to sha in verify.go.
What do you think?

Currently I don't see any actions for micro here.

@gdevenyi
Copy link
Author

From my perspective eget.go#L67 can be generalized by adding a further

Join in here :) zyedidia/eget#114

@gdevenyi
Copy link
Author

Is it just about the fact, that the *.sha files aren't named *.sha256?

Yes. Currently they won't be automatically used by eget.

But shasum itself is capable of checking the provided hash by itself:

That's great, but I don't think eget uses that program directly.

@JoeKar
Copy link
Collaborator

JoeKar commented Sep 30, 2024

Yes. Currently they won't be automatically used by eget.

Yep, I saw it in the code of eget. At least it doesn't behave as shasum at the command line does, while the latter was used to proof the approach I have chosen.

That's great, but I don't think eget uses that program directly.

No it doesn't. It was just the example/proof, that the common command line tool for validating the sha# hashes is familiar with the generic *.sha and validates most probably according to the hash length.

Join in here :) zyedidia/eget#114

I did.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants