[MegaRedHand]

Motivation

ethlambda is getting a Homebrew formula in lambdaclass/homebrew-tap (lambdaclass/homebrew-tap#31), so cutting a release now includes pointing that formula at it. RELEASE.md still listed Homebrew as future work.

Description

• New step 6 in "Cutting a release": the manual formula bump, modeled on ethrex's. It hashes the final tag's source tarball, repackages ethlambda-macos-aarch64 as the arm64_sonoma bottle (with --no-xattrs --no-mac-metadata, so macOS provenance attributes stay out of the archive), attaches it to an ethlambda-vX.Y.Z tap release, and opens the formula PR. "Merge the release branch" becomes step 7.
• "Distribution channels" and the intro now list the tap; apt stays future work.

The tap release is tagged ethlambda-vX.Y.Z because the tap's bare vX.Y.Z tags are ethrex's, and it is created with --latest=false so ethrex's release stays the tap's latest.

[github-actions]

🤖 Kimi Code Review

I'll review this PR diff, which appears to be documentation-only changes to the release process for adding Homebrew distribution.

Review: PR #723 — Homebrew Release Documentation

Summary

This PR adds documentation for publishing ethlambda to a Homebrew tap. No code changes. I'll focus on correctness of the documented procedures and potential operational issues.

---

Issues Found

1. Security: Missing signature verification in bottle creation (RELEASE.md, lines 221-230)

gh release download "v$V" -R lambdaclass/ethlambda -p ethlambda-macos-aarch64 -p SHA256SUMS
shasum -a 256 -c --ignore-missing SHA256SUMS

Problem: The SHA256SUMS file is downloaded from the same untrusted source as the binary. If the release is compromised, both are compromised. The --ignore-missing flag also silently ignores missing checksums for other files.

Suggestion: Document verifying the GitHub release's attestation or GPG signature if available, or note this limitation explicitly:

# Verify GitHub attestation before trusting downloaded artifacts
gh attestation verify ethlambda-macos-aarch64 -R lambdaclass/ethlambda

---

2. Correctness: Race condition in step ordering (RELEASE.md, lines 204-260)

Problem: Step 6 requires the final tag to exist (for source tarball hash), but step 7 merges the release branch. The tag is typically created on the release branch. If the tag is created before merge, the source tarball contains pre-merge code; if after, step 6 can't complete.

Clarify: Explicitly state when the final tag is created relative to merge. The current flow implies:

1. Test RC (step 5)
2. Create final tag on tested commit
3. Run step 6 (needs tag)
4. Merge step 7

This should be explicit to prevent mistakes.

---

3. Operational risk: tar portability (RELEASE.md, line 229)

tar --no-xattrs --no-mac-metadata -czf ...

Problem: --no-mac-metadata requires GNU tar 1.34+ or recent libarchive. Default tar on older macOS (pre-13) or some Linux distributions may not support this flag.

Suggestion: Add version check or fallback:

# Verify tar supports required flags
tar --no-mac-metadata --help >/dev/null 2>&1 || { echo "tar too old; install gnu-tar"; exit 1; }

---

4. Documentation clarity: Bottle naming convention (RELEASE.md, line 230)

"ethlambda-$V.arm64_sonoma.bottle.tar.gz"

Problem: arm64_sonoma hardcodes macOS 14 (Sonoma). What about macOS 15 (Sequoia) or future versions? Homebrew bottles typically use arm64_sonoma as minimum, but this should be documented if it's intentional or if updates are needed per macOS release.

---

5. Minor: Inconsistent tap URL (RELEASE.md, line 258 vs line 204)

• Line 204: lambdaclass/homebrew-tap
• Line 258: lambdaclass/tap (in brew install lambdaclass/tap/ethlambda)

Note: These are actually equivalent in Homebrew (homebrew- prefix is optional), but could confuse readers. Consider adding a parenthetical note.

---

Positive Observations

• The --latest=false flag on tap releases (line 238) correctly prevents interfering with ethrex's latest release — good operational awareness.
• Explicit chmod +x (line 227) handles GitHub release binaries losing executable bits — correct.
• Clear separation of Apple silicon bottle vs. source builds for other platforms — appropriate given CI resource constraints.

---

Verdict

Approve with minor suggestions. The procedure is sound but would benefit from:

1. Adding gh attestation verify for supply chain security
2. Clarifying tag creation timing
3. Adding tar version check for portability

---

Automated review by Kimi (Moonshot AI) · kimi-k2.6 · custom prompt

[github-actions]

🤖 Claude Code Review

Review of PR 723: docs(release): Homebrew formula bump steps

This is a docs-only change to RELEASE.md. It has no code, consensus or security impact, and the steps read clearly. I couldn't run the commands or check the tap's formula here, so the points below come from reading the diff.

Minor points:

1. Step 6.1, tarball hash. gh release download "v$V" --archive=tar.gz writes ethlambda-$V.tar.gz, which matches the shasum line. Check once that this holds with gh's current naming, which is <repo>-<tag-without-v>.tar.gz. If it doesn't, the copy/paste step will fail.
2. Step 6.1, ordering. The text says the tag must be on the tested commit "(step 5)". Confirm that step 5 is actually where the final tag is created. If it isn't, the cross-reference is wrong.
3. Step 6.2, SHA256SUMS check. shasum -a 256 -c --ignore-missing is good because it verifies the binary before repackaging. On macOS the system shasum supports --ignore-missing only in newer Perl versions. If an older macOS ships a shasum without it, mention sha256sum as an alternative.
4. Step 6.2, bottle layout. The bottle is built with ethlambda/<version>/bin/ethlambda. Homebrew bottles usually expect the version directory to match the formula's pkg_version, including any _revision. That's fine for a first release, but a later formula revision would need a rebuilt bottle.
5. Step 6.2, tar flags. --no-mac-metadata is only available in bsdtar from macOS 13 or later. Someone running this on Linux with GNU tar would get an error. A short note such as "run on macOS" would help.
6. Distribution channels. The link text says lambdaclass/tap, while the intro says lambdaclass/homebrew-tap. Both are correct, since brew install lambdaclass/tap/ethlambda resolves to the homebrew-tap repo, but a short clarification would avoid confusion.

Overall, this is good to merge. The --latest=false rationale and the ethlambda-vX.Y.Z tag-naming reason are both documented.

---

Automated review by Claude (Anthropic) · sonnet · custom prompt

[github-actions]

🤖 Codex Code Review

Looks good overall — this PR is docs-only, so none of the consensus-critical areas you listed are affected.

• I did not find code correctness, security, memory-safety, or performance issues in the Rust client itself because the diff only updates RELEASE.md.
• The new Homebrew release steps are coherent with the repo’s current toolchain pin in rust-toolchain.toml:2 and the existing release flow in RELEASE.md:1.

One small thing to tighten:

• RELEASE.md:256 says to update the tap’s rustup toolchain install version if rust-toolchain.toml changed. That’s easy to miss manually; if the tap formula hardcodes this, consider explicitly saying “must match rust-toolchain.toml exactly” to avoid source-build drift between the repo and Homebrew.

No blocker from me otherwise.

---

Automated review by OpenAI Codex · gpt-5.4 · custom prompt