Serious question - What is the benefit of verifying a hash? Are we really worried about file integrity? Why don't people use GPG?
The hash only verifies file integrity, and that the content of the url doesn't switch the script later. But keep in mind in most scenerios, and attacker would also just change the hash listed too (they're usually on the same website). This only mitigates one very specific attack.
Why don't we use GPG here? That way we can verify ownership and file integrity with at minimum TOFU, plus optional manual verification? If we're going through the work of adding a wrapper and all that, we may as well no?
This has the benefit that you only need to import the owner's cert once, all future changes have the same cert. Where hashes are obviously different every time, you have to trust the source of the hash every time it changes. With GPG at the very least you have TOFU with certs - and very best can have better assurance of the initial download too.
EDIT: Just want to clarify - I'm openly asking why the "developer community" is going the direction of hashes for script verification vs GPG signatures.
I don't mean to diminish your project, your project looks fun, and does make verifying hashes easier :)
Because for all of its problems, Web PKI is a working, practical, large scale system of verification and GPG isn't - you don't get much by trying to replicate what your web browser and CAs do for you but clunkier.
In my project I "host" the hash on a different medium, so in order to compromise the file download the attacker would have to compromise both the file hosting server and the hash hosting medium (which in my case is GitHub).
I also don't really display the hashes, as the download only happens when the script is updated, so your current version of the script will check the hash on GitHub vs the hash of the file download from the file hosting server.
EDIT: To be clear, this doesn't solve the problem with the initial install and it is also not related to the Checksum.sh script.
Does the script get the new version url&expected hash from the website alone? Or does it get the expected hash from the website, then calculate the URL from github?
Basically I'm wondering if that prevents just needing to attack the website - if the url to download the update and the expected hash are in the same place then it's still a single point of failure.
The latest file download URL is always the same /latest, hosted on my server.
The version number and latest file hash are also fixed URLs, stored on GitHub.
So for an update, the script checks GitHub for latest version number, if newer it downloads the latest version from my server, computes the hash and compares it to the hash stored on the fixed GitHub URL before proceeding.
I think there's no way to replace the file with a malicious one that will be distributed to the users unless you get access to both my server and the GitHub repository.
It does have the downside still that changes to the website/github might break future updates in a way that isn't (easily) verifiable.
While this is a solution personally I still like the idea of GPG more since it'll work for any new files, works for your new projects automagically, etc.
But I think you did at least fix the future update problem with auto-updates, which is a lot more work then most people put into it so thank you for addressing the issue!
Hash essentially proves that the file you downloaded is the same as the file that was uploaded. It tells you nothing about Who uploaded the file. An attacker could make you download their own file, but then the hash of the file won't match what's published (unless the attacker changes the published hash).
A GPG sig proves that the file was signed & uploaded by the author, which defacto doubles as proof that it's the same file. The idea here is that the author uploads their public key, signs the package with their private key, and now there's an association between the package and the author. An attacker would have to obtain the author's private key, or replace the public key with their own. Changing the public key, however, is a big red flag.
I couldn’t care less if the Chinese government hosts an install script, if there’s no possibility they could have changed a single byte of the script.
Assuming I have a trusted way of knowing the installer script hash (which is a big assumption), I don’t need authentication for the script download, I only need integrity checks.
A hash is the same when the values of the content are the same. But when you get a new (maliciously hacked) install script chances are that you won't have an old hash lying around to check whether the script changed. Any attacker who could swap the sceipt could also swap the hash, unless it is a different channel.
With GPG the developer has a key pair (one private, one public). They can then sign all their scripts with their private key and publish the public one wherever. You can then take that public key and verify that the script has been indeed signed by the developers private key.
Admittedly this is likely the main reason GPG isn't more common place because of the complexity.
This is the overview:
Developer generates a private/public key they use for all of their projects.
You import their public key once - you can verify this from their github, twitter, etc but that's optional.
They can sign a file with their key. You can check this signature against their public key. This will guarantee the file was signed by using that key and is unmodified.
If someone hijacks the website after this point and signs the new downloads with their own key - then you will be able to see it's invalid.
If you manually verify the key then you'll know your initial download is valid - if you trust on first use then you at least know all future files signed from that developer with that cert are valid.
They also are effectively a hash for file integrity.
tl;dr - hashes tell you if a file is changed. Signatures tell you if the file is changed, and who the person that made the file is.
The hash only verifies file integrity, and that the content of the url doesn't switch the script later. But keep in mind in most scenerios, and attacker would also just change the hash listed too (they're usually on the same website). This only mitigates one very specific attack.
Why don't we use GPG here? That way we can verify ownership and file integrity with at minimum TOFU, plus optional manual verification? If we're going through the work of adding a wrapper and all that, we may as well no?
This has the benefit that you only need to import the owner's cert once, all future changes have the same cert. Where hashes are obviously different every time, you have to trust the source of the hash every time it changes. With GPG at the very least you have TOFU with certs - and very best can have better assurance of the initial download too.
EDIT: Just want to clarify - I'm openly asking why the "developer community" is going the direction of hashes for script verification vs GPG signatures.
I don't mean to diminish your project, your project looks fun, and does make verifying hashes easier :)