Since my plugin’s latest release, its scorecard shows two risks: “The main.js release asset has an attestation that failed cryptographic verification” and the same for styles.css. Rescanning does not clear them. Oddly, manifest.json from the same attestation passes.
Steps to reproduce: view the scorecard for readest-highlights (repo: polybjorn/obsidian-readest-highlights, release 1.3.0), or rescan it.
Expected: no attestation risks, since the assets verify with GitHub’s own tooling, exit 0 on both:
gh attestation verify main.js --repo polybjorn/obsidian-readest-highlights
gh attestation verify styles.css --repo polybjorn/obsidian-readest-highlights
Actual: both flagged as failing cryptographic verification.
Earlier releases (1.2.2 and back) used the identical workflow (actions/attest-build-provenance) and always scanned clean, including scans made right after a release, so this looks like a recent change on the verification side rather than in the plugin. One candidate: the GitHub attestations API (/repos/{owner}/{repo}/attestations/sha256:{digest}) now returns "bundle": null plus a short-lived signed bundle_url instead of an inline bundle. A verifier reading the inline bundle field would start failing attestations it previously passed, which matches the timing.
