Skip to content

attestations: batch attestation requests to reduce GH API load #18544

Open
@woodruffw

Description

Verification

Provide a detailed description of the proposed feature

This is a tracking issue for myself.

GitHub ratelimits their attestation APIs. These ratelimits are mostly fine when authenticated, but are severe when unauthenticated. However, even when authenticated, we're currently regularly getting close to them on CI (since the CI performs a lot of attestation verifications while performing bottle builds + test installs).

We can significantly reduce the amount of individual GH API calls we make by batching our attestation lookups. Instead of performing one gh attestation ... subcommand per attestation, we can instead pre-compute the list of attestations to look up and fetch them in a bulk fashion by requesting them in a single gh attestation ... invocation. gh attestation ... should then download them in an appropriate batched fashion internally.

What is the motivation for the feature?

Three main motivations:

  • Reliability/reducing our baseline GH API load: fewer separate downloads means fewer network requests that can fail for reasons outside of our control. It also means fewer hits counted against both our (CI) and user-level API tokens, making it less likely that users will see ratelimiting errors.
  • Performance: doing attestation downloads and verification in bulk upfront can be made embarrassingly parallel, either at the gh level or at the brew level. It also reduces the number of gh subprocesses brew needs to spawn, which are also slow.
  • Post gh transition: downloading the attestations up-front means we can more easily slot sigstore-ruby in for verification.

How will the feature be relevant to at least 90% of Homebrew users?

Reliability and performance, per above.

What alternatives to the feature have been considered?

Two options:

  1. Leave things as they are.
  2. Perform a more aggressive refactor that avoids the attestation APIs entirely, by instead stapling attestations to container manifests/metadata (is this the right term?) and retrieving them in-line with bottle downloads from GHCR. This would bypass the ratelimit concerns with attestations, but might have some undesirable knock-on effects (such as making 3p tap attestation support harder, since not all 3p taps use containers for bottle distribution).

Metadata

Assignees

Labels

featuresNew featuresin progressMaintainers are working on this

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions