Three releases (1.0.13, 1.0.16, 1.0.17) failed Obsidian's review with
"attestation exists but signature is invalid or does not match this
repository" despite trying attest-build-provenance v1, v2, and
actions/attest v4. Decoding the actual published bundles via the
attestations API shows they are well-formed sigstore v0.3 bundles whose
Fulcio certificates correctly identify this repo and workflow — the
verification failure is on the checker's side and not fixable from here.
Since a present-but-unverifiable attestation is a review Error while a
missing one is only a Recommendation, the attest step is removed
(comment in the workflow explains why, so it doesn't get re-added
blindly).
Attestations are permanent and keyed by file digest, and source didn't
change across 1.0.13-1.0.17, so the old broken attestations still cover
the current main.js/styles.css bytes. To escape them:
- esbuild now emits a version-stamped banner comment in main.js (also
makes installed copies identifiable)
- styles.css header comment gains the repo URL
Verified via the API that the new digests have zero attestations.
1.0.13's v2 bump alone didn't fix the invalid-attestation error, so the
workflow now matches the community-documented, verified-working pattern
for Obsidian plugin release attestation more closely:
- Attest manifest.json in addition to main.js/styles.css — our subject-path
list was missing it, unlike every working reference implementation found.
- Switch release creation from a raw `gh release create` shell command to
softprops/action-gh-release@v2 (the action the reference workflow uses),
keeping draft:true and generate_release_notes:true to preserve the
existing draft-then-manually-publish flow.
- Bump actions/checkout and actions/setup-node to v4, npm ci instead of
npm install.
The release workflow was pinned to actions/attest-build-provenance@v1,
which is old enough (pre-dating several major Sigstore trust-root
rotations) that its generated attestations fail cryptographic
verification — exactly the "signature is invalid or does not match this
repository" error on the 1.0.12 release's main.js/styles.css assets.
Bumped to @v2 (current, actively maintained). Same subject-path inputs,
no other workflow changes.
Note: releases 1.0.6 through 1.0.12 likely carry the same broken
attestation and can't be fixed retroactively — only new tags re-run the
workflow.
Addresses plugin-review recommendations: releases had no description
(now auto-generated via --generate-notes), release assets lacked
attestations (now signed via actions/attest-build-provenance), and
vault-enumeration/clipboard usage lacked documented justification.
