plugin: fetch attestation bundles from bundle_url

[Kunalbehbud]

Fixes #2591

Root cause

GitHub stopped embedding sigstore bundles in attestation list responses. As @sarahhodne noted in the issue, this matches the documented breaking change ("Remove the bundle property from attestation list responses. ... Use bundle_url to retrieve the attestation bundle"), except it now applies to the 2022-11-28 API version as well. The endpoint currently returns:

{
  "attestations": [
    {
      "repository_id": 245765716,
      "bundle_url": "https://tmaproduction.blob.core.windows.net/attestations/...json.sn?...",
      "initiator": "user",
      "bundle": null
    }
  ]
}

json.Unmarshal unmarshals null into a *bundle.Bundle without error — it just sets the pointer to nil — and VerifyAttestations passes that nil straight to verifier.Verify, which dereferences it in bundle.(*Bundle).TlogEntries. That's the panic in the issue. It also reproduces in this repo's CI: the build workflow on #2592 hit the same panic in Test_Install_withAttestations (run), and the nightly on master will hit it too.

Changes

1. fetchArtifactAttestations resolves bundle_url. go-github v81 doesn't expose the field, so the endpoint is queried via client.NewRequest/client.Do with a small local struct — this keeps github.ErrorResponse semantics, so isIgnorableAttestationError keeps working for 403/404. When bundle is null or absent, the bundle is downloaded from bundle_url. The blob is served as snappy-compressed JSON (Content-Type: application/x-snappy), so it's snappy-decoded, mirroring what the gh CLI does in getBundle. The download intentionally uses http.DefaultClient: the URL is pre-signed, and API credentials must not be sent to blob storage. If a bundle is ever served uncompressed, the raw body is used as long as it's valid JSON.

2. VerifyAttestations rejects empty bundles instead of crashing. Bundles are now parsed upfront, and a null bundle returns attestation contains an empty sigstore bundle. Even if the API serves something unexpected again, tflint --init fails with an error rather than a SIGSEGV.

Uses github.com/klauspost/compress/snappy, which is already in the module graph as an indirect dependency, rather than adding a new module.

Tests

• Test_fetchArtifactAttestations (new, offline via httptest): embedded-bundle passthrough, bundle_url + snappy, bundle_url + uncompressed fallback, null bundle with no URL, download failure.
• Test_SignatureChecker_VerifyAttestations_errors: new null bundle case — the exact crash input now returns an error.
• Test_Install_withAttestations (existing, live): panicked before this change exactly as reported; now passes end-to-end against the real API (list → download from bundle_url → decompress → verify).

[wata727]

Thank you for working on this. It looks good to me.

As this issue involves a significant bug fix, it was merged as #2600 to ensure a prompt release. Therefore, I am closing this PR. Thank you for your cooperation.