attestation: add initial attestation helpers, integrate into brew install

[woodruffw]

Adds the basic attestation verification APIs, as well as a pre-pour check against HOMEBREW_VERIFY_ATTESTATIONS that verifies the attestation (or backfill as necessary) for bottles from homebrew-core.

See #17019.

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew typecheck with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

[woodruffw]

NB: I haven't written any tests yet; I want to get some eyes on this and then I'll do so once the general approach seems fine 🙂

[Bo98]

Looks good.

Probably don't any of the shell handling when we can just do:

gh = with_env("HOMEBREW_VERIFY_ATTESTATIONS" => nil) do
  ensure_executable!("gh")
end

[woodruffw]

Probably don't any of the shell handling when we can just do:

I was wracking my brain trying to remember ensure_executable! 😅 -- I'll switch to that.

[MikeMcQuaid]

Looking good so far, nice work @woodruffw!

[woodruffw]

Good for another look! I've ratcheted down the typing + removed all of the invasive .sh changes in favor of ensure_executable!.

[MikeMcQuaid]

Approach looks good to me! Some unit tests of Library/Homebrew/attestation.rb would be sufficient for this to get merged.

[woodruffw]

Some unit tests of Library/Homebrew/attestation.rb would be sufficient for this to get merged.

Sounds good, doing today!

[MikeMcQuaid]

Looking good! Would be good to cover a couple more of the missing lines.

[woodruffw]

The coverage should be much better now, but this has revealed a logic error we made during the backfill: the homebrew-core attestations are produced using the bottle filename (e.g. zoro--20211230.monterey.bottle.tar.gz), while the backfilled attestations are bound to a digested filename (e.g. fec7e59a30acea3bf98402e763d648878693f77230541e1f5834176974487f53--zoro--20211230.monterey.bottle.tar.gz).

We could hack around this in the verification, but redoing the backfill is likely to be cleaner. So I propose that we consider this blocked until we re-perform the backfill, which shouldn't take too long.

Edit: I thought about this a bit more, and there's a sound way to handle this different: the prepended hash is SHA256(resource.url), which is both independently computable and provides a nice bit of additional domain binding in the backfill (asserting not only that the backfileld signature is for a specific extant bottle, but that bottle comes from a known URL).

[MikeMcQuaid]

One remaining question and then I'm ✅. Coverage is sufficient, just curious about the new method having supposedly missing coverage.

[MikeMcQuaid]

Seems weird no tests cover this, is this used anywhere right now?

[woodruffw]

The tests currently use a double for it, so I think that's what it doesn't get coverage. Want me to add some separate coverage for it?

[MikeMcQuaid]

Yeh or just double lower in the stack (the owner/tag/rebuild) so it still gets called?

[woodruffw]

Done with 1607d04 -- I went with a separate test since the more invasive double was going to require a lot of nesting that would make the other tests harder to read, but I can shoehorn it in if that's your preference 🙂

[woodruffw]

(I also had to move the BottleSpecification specs to their own file, since RuboCop was complaining about having two RSpec stanzas in bottle_spec.rb.)

[MikeMcQuaid]

Thanks again @woodruffw!