Arch Linux User Repository

After the one time it had the checksum on the PKGBUILD of 3.40-1 it flipped back (to what turns out to be the right one then). Checking again right now, it's still incredibly slow/unstable to download but the checksum has, aside from that one time, always ended up as 91f7b0456619dbfc19940a85566c949ce3718321f32709886df5125c71f0b6b7.

It's good to have confirmation which one is supposed to be the right one (they should really have this on their website or forum release posts honestly...). Now it's not really a gamble any more whether we'd be running something invalid or not.

FWIW, I have been able to reproduce the issue where it throws ERROR: One or more files did not pass the validity check!. I am using yay on EndeavourOS and have been able to delete ~/.cache/yay/winbox and it works the second time, every time. I'm not sure it's a Mikrotik issue, or it would not work so reliably after wiping cache.

Also, this issue reoccurred at 10:00PM PST 10/23, so Mikrotik's fix as of 10/20(previous comment) was either not successful or not present in latest version.

I've contacted Mikrotik and they've fixed the issue:

Thank you for the report.
We've found and fixed the issue.
Please verify if you now receive the accurate value:  91f7b0456619dbfc19940a85566c949ce3718321f32709886df5125c71f0b6b7  

Tried again and after 6 times of the MikroTik server interrupting/terminating the connection, it finally finished the dload and it had the checksum in the PKGBUILD this time.

Well yes, but that's basically saying --yes-i-will-take-this-corrupted-or-virus-invested-file. A checksum mismatch is not something to blindly ignore. And in this case it's not like we can look at the source changes or something.

In general it's weird for there to be different checksums for different people for the same file. That means something is wrong. Whether that is of a malicious cause or not is a different question.

I've grabbed the file again today and it's still the other checksum instead of the one in the PKGBUILD (and also still very slow...).
It would be nice if someone that had the checksum in the PKGBUILD download the binary again and check if it switched to the other checksum or not. If yes, maybe MikroTik replaced it after the initial upload. If not, there might be a regional server/cdn issue or something.

you can always skip hash cheking by using makepkg --skipinteg -si PKGBUILD

As for @abruegmann, @Saduff (initially), @ypoluektovich, @kroloskar and @sshine, I'm also getting 91f7b0456619dbfc19940a85566c949ce3718321f32709886df5125c71f0b6b7 instead of 09e9683e008d09c981e4a5294c78f93e03dede1af19aee8ba794f5ca4aedef04. I've tried trice, all with the same result.
That said, the speed was incredibly slow and I had to retry one of them at least 3-4 times so not sure what's going on here. I'll try again later to see if anything changed.

@kroloskar you need to edit the PKGBUILD, you can do it easy from "app store" and change the version to 3.40 and the first of four checksums with this:

09e9683e008d09c981e4a5294c78f93e03dede1af19aee8ba794f5ca4aedef04

Building winbox... ==> Making package: winbox 3.40-1 (Fri, 13 Oct 2023, 07:23:39) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Found winbox-3.40.exe -> Found winbox.desktop -> Found winbox.png -> Found winbox ==> Validating source files with sha256sums... winbox-3.40.exe ... FAILED winbox.desktop ... Passed winbox.png ... Passed winbox ... Passed ==> ERROR: One or more files did not pass the validity check! ... can someone explain how to deal with it? When you go to the website, the file you downoload is winbox64 not winbox-3.40... could this be the problem?