Describe the bug
Auto-update on an Intel Mac fails with Update failed: The signature verification failed (observed updating a Block-signed 0.4.22 → 0.4.24). The cause is in the buzz-desktop-latest updater release: both macOS platform entries in latest.json point to the same unversioned Buzz.app.tar.gz, but carry different signatures — the two mac release jobs upload under one shared filename and the last upload wins, so at most one architecture's signature can ever verify.
latest.json as of version: 0.4.24:
| platform |
url |
signature |
darwin-aarch64 |
…/buzz-desktop-latest/Buzz.app.tar.gz |
…d1VIeGs3a3REd2QyQ1hYeTNqSlhhL3lUK0RnPT0K |
darwin-x86_64 |
…/buzz-desktop-latest/Buzz.app.tar.gz |
…cXdrd3pNOWxsbmlZaEVOUzJUZUV2dFJTSUNRPT0K |
linux-x86_64 |
…/Buzz_0.4.24_amd64.AppImage |
(versioned, per-file) |
windows-x86_64 |
…/Buzz_0.4.24_x64-setup_alpha-unsigned.exe |
(versioned, per-file) |
Same URL, two different signatures. The file currently at that URL is the arm64 build:
$ gh release download buzz-desktop-latest -R block/buzz -p Buzz.app.tar.gz
$ tar -xzf Buzz.app.tar.gz && file Buzz.app/Contents/MacOS/buzz-desktop
Buzz.app/Contents/MacOS/buzz-desktop: Mach-O 64-bit executable arm64
So every darwin-x86_64 client fails signature verification — and the failure is actually load-bearing: if the x86_64 signature ever did verify, Intel users would be handed an arm64 binary.
Note the asset list also shows every Linux/Windows artifact since 0.3.20 accumulating in buzz-desktop-latest with versioned names, while macOS alone uses the overwriting unversioned name — which is presumably how the collision was introduced.
To Reproduce
- Install
Buzz_0.4.22_x64.dmg (Intel) from the v0.4.22 release.
- Settings → check for updates → install.
Update failed: The signature verification failed.
Expected behavior
Each mac architecture publishes its own updater artifact (e.g. Buzz_<version>_aarch64.app.tar.gz / Buzz_<version>_x64.app.tar.gz, matching the versioned naming already used for Linux/Windows), with latest.json pointing each darwin-* key at its own file.
Environment
- Installed app: Buzz 0.4.22, Developer ID
Block, Inc. (EYF346PHUG), notarized, Mach-O thin x86_64
- macOS on Intel (x86_64), Darwin 25.5.0
buzz-desktop-latest state as of 2026-07-24
Describe the bug
Auto-update on an Intel Mac fails with
Update failed: The signature verification failed(observed updating a Block-signed 0.4.22 → 0.4.24). The cause is in thebuzz-desktop-latestupdater release: both macOS platform entries inlatest.jsonpoint to the same unversionedBuzz.app.tar.gz, but carry different signatures — the two mac release jobs upload under one shared filename and the last upload wins, so at most one architecture's signature can ever verify.latest.jsonas ofversion: 0.4.24:darwin-aarch64…/buzz-desktop-latest/Buzz.app.tar.gz…d1VIeGs3a3REd2QyQ1hYeTNqSlhhL3lUK0RnPT0Kdarwin-x86_64…/buzz-desktop-latest/Buzz.app.tar.gz…cXdrd3pNOWxsbmlZaEVOUzJUZUV2dFJTSUNRPT0Klinux-x86_64…/Buzz_0.4.24_amd64.AppImagewindows-x86_64…/Buzz_0.4.24_x64-setup_alpha-unsigned.exeSame URL, two different signatures. The file currently at that URL is the arm64 build:
So every darwin-x86_64 client fails signature verification — and the failure is actually load-bearing: if the x86_64 signature ever did verify, Intel users would be handed an arm64 binary.
Note the asset list also shows every Linux/Windows artifact since 0.3.20 accumulating in
buzz-desktop-latestwith versioned names, while macOS alone uses the overwriting unversioned name — which is presumably how the collision was introduced.To Reproduce
Buzz_0.4.22_x64.dmg(Intel) from the v0.4.22 release.Update failed: The signature verification failed.Expected behavior
Each mac architecture publishes its own updater artifact (e.g.
Buzz_<version>_aarch64.app.tar.gz/Buzz_<version>_x64.app.tar.gz, matching the versioned naming already used for Linux/Windows), withlatest.jsonpointing eachdarwin-*key at its own file.Environment
Block, Inc. (EYF346PHUG), notarized, Mach-O thin x86_64buzz-desktop-lateststate as of 2026-07-24