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

Resource should allow specifying checksum other than SHA-256, e.g. SHA-512. #19059

Closed
1 task done
kevemueller opened this issue Jan 8, 2025 · 1 comment
Closed
1 task done
Labels
features New features

Comments

@kevemueller
Copy link

Verification

Provide a detailed description of the proposed feature

Formula resources should allow to have other than SHA-256 checksums added for verification purposes.
E.g.

  resource "myresource" do
    url "https://download.example.com/myfile"
    sha512 "cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e"
  end

Ideally the resource should allow multiple checksums and an optional size value as well.

What is the motivation for the feature?

I need to add resources to the formula for which only SHA-512 checksums are verifiably published. By adding the sha512 checksum into the formula, anybody can verify that the formula uses the unaltered resource.

If multiple checksums are provided, this further increases the certainty that the file is legit.
Adding the file length attribute protects against attack on the hash which stuff data at the end of the original stream.

How will the feature be relevant to at least 90% of Homebrew users?

SHA-512 is picking up in adoption, so the relevance will grow over time.

What alternatives to the feature have been considered?

Downloading/verifying/sha256-ing and putting that hash in to the resource description is not equivalent, as it loses the signature of the manifest file that original file's SHA-512 checksum had.

There is no true alternative to the feature, in fact, the only alternative is not to have a checksum at all, which is very undesired and generates warnings for a good reason.

@kevemueller kevemueller added the features New features label Jan 8, 2025
@MikeMcQuaid
Copy link
Member

We'll continue to use sha256 as our checksum of choice for now. It's much easier if things are globally consistent there. We'll consider sha512 adoption in future. Thanks!

@MikeMcQuaid MikeMcQuaid closed this as not planned Won't fix, can't repro, duplicate, stale Jan 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
features New features
Projects
None yet
Development

No branches or pull requests

2 participants