3 ms·

> 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 wo

by XCSme 4y ago

> 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 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.

thewataccount 4y ago
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.
- XCSme 4y ago
  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.
  - thewataccount 4y ago
    Yeah I think that should work. 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!

by XCSme 4y ago

thewataccount 4y ago

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.

XCSme 4y ago
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.
- thewataccount 4y ago
  Yeah I think that should work. 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!