The macOS installer had to be fixed in September because it took the first sha256: in the release JSON regardless of which asset it belonged to. That fix made the scrape correct. It did not remove the reason the scrape exists, and the scrape is still the only path on macOS.
Compare the two installers, because one of them cannot have this bug at all.
install-linux.sh builds the asset name from the tag and the arch, then fetches the digest from the published <asset>.sha256 sitting beside it:
asset="plaza-${tag#v}-linux-$arch.tar.gz"
curl -fsSL -o "$tmp/$asset.sha256" "$url.sha256" || die ...
want="$(awk '{print $1}' "$tmp/$asset.sha256")"Nothing is chosen by position. There is no list to pick the wrong element out of.
install-macos.sh has to do this instead:
digest="$(printf '%s' "$json" | tr -d '\n' | tr '{' '\n' | grep 'macos\.zip' \
| grep -o 'sha256:[0-9a-f]\{64\}' | head -1 | cut -d: -f2 || true)"Correct today. Also three transformations and two greps deep, and it exists only because there is nothing better to read.
Why there is nothing better to read
The macOS zip publishes no checksum. Confirmed on the latest release of both repos:
plaza-0.19.0-linux-aarch64.tar.gz plaza-0.19.0-linux-aarch64.tar.gz.sha256
plaza-0.19.0-linux-x86_64.tar.gz plaza-0.19.0-linux-x86_64.tar.gz.sha256
Plaza-v0.19.0-macos.zip (nothing)
package-linux.sh writes its .sha256 and release.yml uploads both. package-macos.sh writes no sidecar and the macOS job uploads one file.
What to do
Publish the sidecar for the macOS zip the way the Linux job already does, then install-macos.sh reads it exactly as install-linux.sh does and the JSON parsing is deleted rather than repaired. That also gives a reader a digest they can check by hand from the release page, which is the point of publishing one.
scripts/check-macos-installer.sh keeps its fixture test for as long as the scrape exists, and can go when it does.
Same change in zig-nostr/notary: the two installers and the two release workflows are copies of each other, which is why the original bug was in both.
Done
A tagged release carries Plaza-vX.Y.Z-macos.zip.sha256, install-macos.sh verifies against it, and no installer in either repo picks an item out of a list by position.
The macOS installer had to be fixed in September because it took the first
sha256:in the release JSON regardless of which asset it belonged to. That fix made the scrape correct. It did not remove the reason the scrape exists, and the scrape is still the only path on macOS.Compare the two installers, because one of them cannot have this bug at all.
install-linux.shbuilds the asset name from the tag and the arch, then fetches the digest from the published<asset>.sha256sitting beside it:Nothing is chosen by position. There is no list to pick the wrong element out of.
install-macos.shhas to do this instead:Correct today. Also three transformations and two greps deep, and it exists only because there is nothing better to read.
Why there is nothing better to read
The macOS zip publishes no checksum. Confirmed on the latest release of both repos:
package-linux.shwrites its.sha256andrelease.ymluploads both.package-macos.shwrites no sidecar and the macOS job uploads one file.What to do
Publish the sidecar for the macOS zip the way the Linux job already does, then
install-macos.shreads it exactly asinstall-linux.shdoes and the JSON parsing is deleted rather than repaired. That also gives a reader a digest they can check by hand from the release page, which is the point of publishing one.scripts/check-macos-installer.shkeeps its fixture test for as long as the scrape exists, and can go when it does.Same change in
zig-nostr/notary: the two installers and the two release workflows are copies of each other, which is why the original bug was in both.Done
A tagged release carries
Plaza-vX.Y.Z-macos.zip.sha256,install-macos.shverifies against it, and no installer in either repo picks an item out of a list by position.