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