homebrew: use Releases API digest for Cask checksum

[mjcheetham]

The release-homebrew workflow previously delegated checksum computation to the third-party action mjcheetham/asset-hash, which downloads the release asset and hashes the bytes locally. GitHub has been observed to occasionally serve an HTML error page (the "unicorn" page) with a 200 status code in place of release-asset content. When that happens the local hash succeeds against the wrong bytes and an incorrect SHA-256 ends up in the Cask, which then prevents users from installing.

This is exactly what happened with v2.54.0.vfs.0.2, reported in microsoft/homebrew-git#102: the recorded checksum hashed the unicorn page (8e8052a0...) rather than the .pkg (983dd1b1...).

The GitHub Releases API itself reports the asset's SHA-256 in the digest field of every asset entry, computed server-side when the asset is uploaded. Read that value directly instead of recomputing locally, so a corrupted download can no longer poison the checksum.

The replacement step uses gh api (already available on ubuntu-latest) and emits collapsible log groups with the release metadata, the full asset list (name, size, digest), and the full selected-asset record. If the API ever returns something bogus again, the workflow run will contain everything needed to diagnose it without re-running the release.

Asset selection mirrors the previous regex (git-(.*)\.pkg); the step fails fast if zero or multiple assets match, or if the digest is missing, non-sha256, or not a 64-character hex string.

[dscho]

Slightly on the verbose side ;-) But it will do the job.

[mjcheetham]

Slightly on the verbose side

I agree, but given the lack of trust in the GitHub APIs themselves to behave themselves, the inability to reproduce errors, and the impact of getting it wrong (thousands of users are unable to update or install, or leaving a possible gap for something malicious skirting through), the more verbose we are the better.