toolchains_arm_gnu icon indicating copy to clipboard operation
toolchains_arm_gnu copied to clipboard

Checksum mismatch due to security error

Open pwyliu opened this issue 2 months ago • 2 comments

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.

pwyliu avatar Nov 26 '25 02:11 pwyliu