Nonportable
Nonportable copied to clipboard
asio4all-np can't pass hash check because hash changes each download
Bug Report
asio4all-np: [name of package which has bug(s)]
Current Behaviour
Attempting to install this package will always result in a failed hash check. Repeated attempts reveal a different hash each time.
Expected Behaviour
The hash should be the same each download so that it can install correctly.
Additional context/output
Even after submitting an issue to have the hash check fixed, which got corrected, it's still broken due to the hash changing each time. Here's a few examples with multiple subsequent attempts at installing:
URL: https://www.asio4all.org/downloads_11/ASIO4ALL_2_15_English.exe
First bytes: 3C 21 64 6F 63 74 79 70
Expected: 5aa4aa463197a42e0fe59d921c19380a7444707fff0e6f3e9eff5081768a3136
Actual: 1ddcbe352f0ed3ede659e4761143223ed949d435f4248e21be1af203925d1570
-
URL: https://www.asio4all.org/downloads_11/ASIO4ALL_2_15_English.exe
First bytes: 3C 21 64 6F 63 74 79 70
Expected: 5aa4aa463197a42e0fe59d921c19380a7444707fff0e6f3e9eff5081768a3136
Actual: 7bf52ba2e6a14170e99f0ddda91e13f92287d59e5bac76d8239045610956e55a
-
App: nonportable/asio4all-np
First bytes: 3C 21 64 6F 63 74 79 70
Expected: 5aa4aa463197a42e0fe59d921c19380a7444707fff0e6f3e9eff5081768a3136
Actual: d9db0c703f28ad8ca0d7cfceb8b21fb81f76d2828164313d4c42aca99a81c3e6
-
URL: https://www.asio4all.org/downloads_11/ASIO4ALL_2_15_English.exe
First bytes: 3C 21 64 6F 63 74 79 70
Expected: 5aa4aa463197a42e0fe59d921c19380a7444707fff0e6f3e9eff5081768a3136
Actual: 372566f14288354e8721ae4b44689852d9f020de4ac44a7d69af4ac9fe070c22
-
URL: https://www.asio4all.org/downloads_11/ASIO4ALL_2_15_English.exe
First bytes: 3C 21 64 6F 63 74 79 70
Expected: 5aa4aa463197a42e0fe59d921c19380a7444707fff0e6f3e9eff5081768a3136
Actual: d78bcf18cc44e89678317a6692a90e4b37b1628c200115495492184bf35cabcf
-
URL: https://www.asio4all.org/downloads_11/ASIO4ALL_2_15_English.exe
First bytes: 3C 21 64 6F 63 74 79 70
Expected: 5aa4aa463197a42e0fe59d921c19380a7444707fff0e6f3e9eff5081768a3136
Actual: 877d8f75f9726278655e62fe1c517cc084793092ae12339e01edb1296bdb7bab
-
URL: https://www.asio4all.org/downloads_11/ASIO4ALL_2_15_English.exe
First bytes: 3C 21 64 6F 63 74 79 70
Expected: 5aa4aa463197a42e0fe59d921c19380a7444707fff0e6f3e9eff5081768a3136
Actual: f6dbb23ab554729233a869788cf766cedc33dc5ba6ebc6dc61bfc52c203b5aa0
Possible Solution
System details
Windows version: 10
OS architecture: 64bit
PowerShell version: 5.1.19041.1682
Additional software: none [(optional) e.g. ConEmu, Git]
Scoop Configuration
{
"last_update": "2023-06-29T17:09:58.5084214-04:00",
"aria2-enabled": true,
"scoop_branch": "master",
"scoop_repo": "https://github.com/ScoopInstaller/Scoop"
}
In case you're not aware, hashes (MD5, SHA-1, etc) are computed based on a file's size/content. Expecting an installer's hash to remain static through subsequent release versions is like expecting the time and date to be the same every time you check your watch.
The only caveat I can think of where the hash doesn't change is if the installer is just a static script that parses available releases on their site and downloads the latest one. Even if it's a PWA/Electron-based app, there should at least be minor library config/version string updates in the package which would will change the hash value.
Makes sense, but the hash changes each time for the same release.
I looked into it, and it turns out they're not the same releases; the dev is just using poor file naming conventions. They're all version 2.15, but each one is a different Beta release. They should at least be doing something like this:
ASIO4ALL_2_15_beta_1_English.exe
ASIO4ALL_2_15_beta_2_English.exe
ASIO4ALL_2_15_beta_3_English.exe
Oddly enough, I just tracked down the download link for a beta release, and it does in fact label the file correctly.
https://asio4all.org/downloads/ASIO4ALL_2_15_Beta1_English.exe
Here's a link from the downloads page as well, which I noticed is using a different URL than the bucket definition uses.
https://asio4all.org/downloads/ASIO4ALL_2_15_English.exe
If you do want to include the beta releases, the bucket def needs to be refactored, as the RegEx and arg parse are only configured to handle files with major_minor_English.exe
https://github.com/ScoopInstaller/Nonportable/blob/master/bucket/asio4all-np.json
That also isn't accurate to what is happening...
You can recreate what I'm seeing very easily, simply run
scoop install asio4all-np
Run it, hit your up arrow, then run it again... and again... and again... note that each time the actual hash value that it receives changes. This isn't a case of it grabbing the wrong hash value because the developer keeps updating the file - there's no way this file's location is getting updated every 2 seconds (or however long it takes for the command to finish and me to hit my up arrow and press enter again).
Looking at the top comment on this version's release, however, it doesn't appear to be a problem unique to scoop.
When trying to update ASIO4ALL to version 2.15 using winget, I get the following output:
Found ASIO4ALL [MichaelTippach.ASIO4ALL] Version 2.15 This application is licensed to you by its owner. Microsoft is not responsible for, nor does it grant any licenses to, third-party packages. Downloading https://www.asio4all.org/downloads_11/ASIO4ALL_2_15_English.exe 299 KB Installer hash does not match. Please check if your installer in the winget repository has been compromised, or recalculate and fix your installer hash.
The next comment sheds some light:
If you follow the original link, it ends up in an redirect – that’s why. Looks like winget uses Deep Linking. Which is highly controversial, mildly put.
That seems to track with what you discovered... the intended file path doesn't appear to be "downloads_11" anymore... now it's just "downloads".
ie:
Bad link
https://www.asio4all.org/downloads_11/ASIO4ALL_2_15_English.exe
Good Link
https://www.asio4all.org/downloads/ASIO4ALL_2_15_English.exe
As a quick test, I changed the download link in the manifest to the "downloads" version instead of the downloads_11 version of the link. While it didn't result in a successful install, what I could at least confirm was that the hash value remained the same each time I reran the command.
I could fix it myself here... though I'm not sure I fully understand how the hash-update bot here works, and don't want to throw a wrench into its processes. At the very least, I'll attempt to submit a pull request, and let you guys figure out the best way to merge what I'm doing.
Ah crud I completely missed the contributing guideline, sorry... so this isn't in its own "develop" branch with regression tests (I don't really know how to do what you're doing properly, so you can educate me if you feel inclined, I do dev work for a living and could use the extra practice).
What I can say is I tested this link and this hash value in a locally-installed copy of the manifest file and can confirm it'll download and install the file correctly.
Nice. Sadly I don't have maintainer rights on this repo so I can't keep the ball rolling. You could always ping them on the Discord or Gitter chats linked in the main repo though.
Also, maybe I'm missing something, but at first glance it appears that the github actions to run the tests against your changes should be initiated via the pull request itself, thus giving the approvals. To think I used to sell CI software and now can't even keep up with all the new tech.
Closed via 6170476