Skip to content

Move the tap to 0.8.0 and make it a release step - #20

Merged
Zenofex merged 1 commit into
mainfrom
chore/tap-0.8.0
Sep 28, 2026
Merged

Zenofex merged 1 commit into
mainfrom
chore/tap-0.8.0

Conversation

@Zenofex

@Zenofex Zenofex commented Sep 28, 2026

Copy link
Copy Markdown
Contributor

Follow-up to the 0.8.0 release. The live tap is already updated at BootIntel/homebrew-tap@eca8bf0; this fixes the repo side.

Two things

The in-repo reference copy was stale. It sat at 0.5.0 while 0.6.0, 0.6.1 and 0.7.0 shipped, under a header claiming it tracked the latest release. It advertised checksums for archives nobody would install. It is now byte-identical to the published formula from the class Bootintel declaration onward, so a diff between the two is a real finding rather than noise.

The cause was the checklist, not carelessness. docs/releasing.md mentioned the tap only under one-time setup, never in the numbered list for cutting a release. It is now step 7, which is the part that stops this recurring.

On the checksums

They were read out of the release's SHA256SUMS and paired with each url line programmatically, not transcribed. A wrong digest makes brew install fail with a checksum mismatch, which to a user is indistinguishable from a compromised download.

The x86_64-linux archive was independently downloaded, checked against SHA256SUMS, extracted and run (bootintel 0.8.0, verdict and --interrupt-autoboot both present) before any of this went out.

No code changes.

🤖 Generated with Claude Code

The tap itself is already at 0.8.0 (BootIntel/homebrew-tap@eca8bf0), with the
four checksums read out of the cli-v0.8.0 SHA256SUMS artifact and paired with
each url line programmatically rather than transcribed. A wrong digest makes
`brew install` fail with a checksum mismatch, which reads to a user like a
compromised download.

Two fixes here. The in-repo reference copy sat at 0.5.0 while 0.6.0, 0.6.1 and
0.7.0 shipped, so it was advertising checksums for archives nobody would
install, under a header claiming it tracked the latest release. It is now
byte-identical to the published formula from the class declaration onward, so a
diff between the two is a real finding rather than noise.

The cause was process, not carelessness: docs/releasing.md mentioned the tap
only under one-time setup, never in the numbered list of things to do when
cutting a release. It is now step 7, which is what stops this recurring.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@Zenofex
Zenofex merged commit 0a477cd into main Sep 28, 2026
11 checks passed
@Zenofex
Zenofex deleted the chore/tap-0.8.0 branch September 28, 2026 08:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant