Checksum mismatch due to security error
Hello, we've noticed an issue today in our Bazel builds. When we are trying to download files from the ARM developer website, checksums do not match. I believe this is because developer.arm.com is returning some kind of security challenge for the Bazel user agent. Since the response is a 200, Bazel downloads the page content and then of course expected checksums do not match.
You can replicate this as shown below with an example URL:
# Returns a 302 redirect to the payload
curl -v https://developer.arm.com/-/media/Files/downloads/gnu/13.2.rel1/binrel/arm-gnu-toolchain-13.2.rel1-x86_64-arm-none-eabi.tar.xz?rev=e434b9ea4afc4ed7998329566b764309&hash=688C370BF08399033CA9DE3C1CC8CF8E31D8C441
# Returns a 200 and some sort of security challenge page
curl -A "bazel/8.3.1" -v https://developer.arm.com/-/media/Files/downloads/gnu/13.2.rel1/binrel/arm-gnu-toolchain-13.2.rel1-x86_64-arm-none-eabi.tar.xz?rev=e434b9ea4afc4ed7998329566b764309&hash=688C370BF08399033CA9DE3C1CC8CF8E31D8C441
Since the real files are hosted on Azure, I don't know if this is a proper fix but you could link to them directly instead. I tried modifying my lock file to use the canonical URL and it seemed to work fine. So that'd be linking to something like this:
https://armkeil.blob.core.windows.net/developer/Files/downloads/gnu/13.2.rel1/binrel/arm-gnu-toolchain-13.2.rel1-aarch64-arm-none-eabi.tar.xz
I'm not familiar with this ecosystem so I'm hesitant to make the PR in case that's not appropriate, but I'm pretty sure that would work from a technical standpoint.