trailofbits / trailofbits/coop

Make the attestation-API fallback credential-free for pre-bundle releases

Open
#423 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
243
Forks
13
Avg merge
1d 20h
Merged PRs (30d)
30

Description

Follow-up from review of #421 (comment).

Background

#421 makes attestation verification credential-free by publishing the Sigstore bundle
as an attestations.jsonl release asset and verifying it with gh attestation verify --bundle. That only helps releases that carry the asset. Releases published before it
existed — including v0.5.4, which is latest today — still verify through the
GitHub attestations API, where gh always attaches its stored token, so the request
403s under trailofbits SAML enforcement (or exits 4 with no credential at all).

So the reported symptom persists for every user until the next release ships, and
permanently for VERSION=v0.5.x pinned installs.

Observation

The attestations API is readable anonymously. Only gh attaching a token turns public
data into a 403. Fetching the bundle directly and feeding it to --bundle therefore
verifies old releases with no credential. Verified against v0.5.4 with zero
credentials:

curl -fsS ".../repos/trailofbits/coop/attestations/sha256:$D" \
  | jq -c '.attestations[].bundle' > b.jsonl
gh attestation verify coop.tar.gz --repo trailofbits/coop --bundle b.jsonl   # exit 0

Scope

  • src/update.rsserde_json and the HTTP capture helper already exist, so the
    fallback in fetch_attestation_bundle could build the bundle itself instead of
    handing the API call to gh. That removes the credential-requiring path entirely.
  • install.sh — costs a jq dependency, so it wants gating on has jq with the
    current API path kept as the last resort.

Notes: the unauthenticated API is rate-limited to 60 req/hr/IP, which is fine for a
fallback. Verification strength is unchanged either way — the bundle is signed and
--repo still pins the signer identity, so a substituted bundle fails.

Related: #422 (Option A there is the larger in-process-verification direction; this is
the cheap subset that only changes bundle transport).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with fetch_attestation_bundle in src/update.rs and trace the fallback from the existing HTTP capture helper, then inspect the verification flow and jq gating in install.sh. Done means pre-bundle releases such as v0.5.4 can verify without credentials, while the existing API path remains the last resort when jq is unavailable.

Written by the indexing model from the issue text.

Assessment

Tech stack
github, rust, shell
Domain
cli, release, security
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.