Use pre-built attested binaries for supported platforms

[heaths]

Output of brew config

HOMEBREW_VERSION: 6.0.17
ORIGIN: https://github.com/Homebrew/brew
HEAD: 4dacfe77a24dead72de749c0876028b77b99cd04
Last commit: 2 days ago
Branch: stable
Core tap: N/A
Core cask tap: N/A
HOMEBREW_PREFIX: /home/linuxbrew/.linuxbrew
Homebrew Ruby: 4.0.6 => /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/4.0.6/bin/ruby
CPU: dodeca-core 64-bit arm
Clang: N/A
Git: 2.55.0 => /home/linuxbrew/.linuxbrew/bin/git
Curl: 8.5.0 => /bin/curl
Kernel: Linux 6.18.33.2-microsoft-standard-WSL2 aarch64 GNU/Linux
Landlock ABI: 7
OS: Ubuntu 24.04.4 LTS (noble)
WSL: 2 (Microsoft Store)
Windows: Windows 11 Enterprise (25H2) [26200.9168]
Host glibc: 2.39
Host libstdc++: 6.0.33
/usr/bin/gcc-13: 13.3.0
/usr/bin/ruby: N/A
glibc: N/A
gcc@13: N/A
gcc: N/A
xorg: N/A

Output of brew doctor

Your system is ready to brew.

Description of issue

My release pipeline builds and packages binaries for platforms that will support bottles, and then attests them. These binaries are uploaded to the release and indeed are verifiable with the attestation endpoint.

But when my tap is notified, it rebuilds the binaries as part of the formula. I've been looking through documentation about how I can just use the binaries I already packaged and attested—they should already have the right names to make it easy. Since I have my own tap I'm pretty much free to do whatever is necessary, though it'd be great if it was compatible with the official tap—certainly not required.

I'm aware I can write a formula that just downloads these files but then doesn't that lose the ability to verify the hashes? Is there any GitHub-specific functionality I can use that would query GitHub directly for the release download hashes, or is that something I'd have to write myself as part of the formula.

I'm trying to retain as much as the default bottling functionality as possible but don't want them rebuilt so that attestation still validates.

[p-linnane]

Downloading the release artifacts directly would not lose checksum verification, since each platform-specific URL can have a fixed sha256 in the formula. You could install those binaries and still produce bottles without rebuilding, but the resulting bottles are new artifacts and would not be covered by the upstream archive attestations. If preserving the exact attested artifacts is the priority, a cask is probably the cleaner fit.

[MikeMcQuaid]

We don't support "bring your own binaries" for formulae. That's what casks are for.

[heaths]

I'm not sure what benefit additional attestation would bring, but we have no hooks for that since brew bottles are independent of upstream vendors in the same way the packages in the Debian or fedora repositories are.

Example,

gh attestation verify $(which myexe)

...or whatever attestation people want to use. That's why I asked about hooks to attest built binaries before packaging. I completely agree you shouldn't hardcode to a particular attestation vendor.

[SMillerDev]

How is that better or even really different than brew verify something? I still don't see what an additional attestation provides.

[heaths]

For starters, that failed with an "attestation not found" for a formula built from source that was used to build an otherwise attested binary in my release page. So if it's supposed to work, it didn't.

But I'm coming at this from the perspective of build machines that are validating binaries themselves. Did the binary come from brew? Downloaded directly? Apt or rpm? Shouldn't matter. If our CI is attesting binaries, it only knows the path, hence my example of gh attestation verify $(which myexe).

[cho-m]

For formulae, Homebrew will perform binary modifications to support relocation. This means the digest can change from the built binary to the bottled binary and finally for the user installed binary. Instead, the bottle is a fixed artifact and makes more sense to generate an attestation for.

If this doesn't meet your requirements, then you should use a Cask as previously recommended.

[heaths]

and finally for the user installed binary

That may indeed be a problem. I'll have to consider whether the hassle of notarization is worth it.

Regardless, is it expected that brew verify only seems to verify attestation of official tap bottles?

Error: HTTP 404: Not Found (https://api.github.com/repos/trailofbits/homebrew-brew-verify/attestations/sha256:a1458f4674cf11b11779cab204108a7ec020adf2e0ef624a8bd9b27b972827a3?per_page=30&predicate_type=https%3A%2F%2Fslsa.dev%2Fprovenance%2Fv1)

From my tap, I'd expect it to use my user/org and tap repo to query attestations.

[cho-m]

Some commands/features may not support 3rd party taps yet. I expect brew verify was only written to handle core formulae bottle attestations. Contributions are welcome to expand this to work with taps or to change documentation to make restriction more obvious.