Earlier quoted context omitted.
> would also just change the hash listed too 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 h…
Interesting idea, 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 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.