v0.1.0: dotnet_toolchain.wasm.sha256 does not match the wasm asset

[Fireblade954]

The v0.1.0 release assets are inconsistent:

$ sha256sum dotnet_toolchain.wasm        # downloaded from the release
c4277edcb30e33106cbf957acb94e914ecefca6741baf2157f5692216e68e9be

$ cat dotnet_toolchain.wasm.sha256       # published alongside it
fce48280888903189f8baba82ed9fe1958c92c80164daedcb5735987b91dcf93

Reproducible across downloads (gh CLI and curl), so it is not a corrupted transfer — one of the two assets appears to come from a different build/upload. Anyone verifying the checksum before vendoring the binary will reject the artifact.

[Wtiben]

Confirmed, and thanks for including the hashes, that made it quick to check.

The wasm is the good one. It hashes to c4277edc... and matches its ghcr OCI layer byte for byte, so both distribution channels agree with each other. fce48280... matches nothing we publish, so the .sha256 is the odd artifact out.

It comes from moonrepo/build-wasm-plugin, which hashes something other than the file it leaves in builds/. Our release workflow uploaded both as they came, so this affected every release rather than just v0.1.0.

Fixed in two places:

• fix(ci): compute the release checksum from the published wasm #4 recomputes the checksum from the exact file the release step uploads.
• I replaced the v0.1.0 .sha256 asset in place, so it verifies now instead of only on the next release. The format is unchanged (bare hash, no trailing newline) and a fresh download should give you c4277edc....

One thing worth knowing for the vendoring case: moon never reads the .sha256, it uses the wasm bytes it caches, so the binary itself was always the right one. The checksum file was the only broken part.