Otherwise this just shows a message like
Failed to verify attestation. Retrying in 27...
which is a little vague. Let's make it clear that that refers to
seconds.
I don't think I've seen an `InvalidAttestationError` that wasn't some
sort of network problem (e.g., rate limit, connection timeout, 503).
Let's emit a warning instead of erroring out.
Note that `MissingAttestationError` is still fatal, and that will still
produce errors in CI.
I'm declaring bankruptcy on this entire approach:
1. We can attempt to match on versions, but this will fail
when the version of `gh` installed is built from `HEAD`
or similar.
2. We can match on dates instead (since `gh --version` also includes
the date), but this is even more brittle + implies a support
contract we don't actually have (we don't actually want
to say we support random dated builds between public releases
of `gh`).
This moves us back to a simpler approach: if `gh` is present,
we use it. If `gh` is not present, we attempt to install it
with `ensure_executable!`. If the user's `gh` is present but too old,
it'll fail during attestation verification with a reasonable error,
which IMO is fine for now since this is all still in beta.
Signed-off-by: William Woodruff <william@yossarian.net>
This adds a new method to either move the `gh` formula to the front
of the formula list to be installed or checks that the `gh` formula
is already installed some other way.
Take 2 of https://github.com/Homebrew/brew/pull/17692 but with:
- provide and document `HOMEBREW_NO_VERIFY_ATTESTATIONS`
- don't try to run unless there's GitHub credentials
- don't try to run unless `gh` is installed
- don't try to run in CI
While we're here:
- split out a `Homebrew::EnvConfig.devcmdrun?` helper method
- add some missing `Homebrew::EnvConfig.github_api_token` presence
checks
Add the (for now undocumented) `HOMEBREW_NO_VERIFY_ATTESTATIONS` to
disable attestation verification if it's having issues or when doing
development.
While we're here, do a little style cleanup too.
This widens the beta to include people with developer mode enabled,
as well as those with HOMEBREW_DEVELOPER set in their environment.
Signed-off-by: William Woodruff <william@yossarian.net>
Some backfilled bottle signatures were signed from a branch, and others
from main, so the signing workflow is slightly different which causes
some bottles to incorrectly fail when checking their attestation (apr
for example). The simplest way to solve this is just removing the
backfill repo `cert-identity` check and just rely on the repository and
attestation date falling before our cutoff. This shouldn't meaningfully
affect security because if somehow someone could generate false backfill
attestations from a different workflow (the only case this protects
against), we will still catch it because the attestation would have been
generated after our cutoff date.
