Metafetch 0.1.6 — every release asset cryptographically attested

Every release asset of Metafetch is now cryptographically attested back to its source code — install with the same proof-of-build verification GitHub uses for its own releases.

Why care?

When you install a community plugin, you trust that the bytes downloaded into <vault>/.obsidian/plugins/metafetch/ were actually built from the source code you can read on GitHub. Most plugins ask you to take that on faith. Starting with 0.1.6, Metafetch ships with GitHub artifact attestations — a sigstore-backed cryptographic signature linking each main.js, manifest.json, and styles.css back to the exact commit and GitHub Actions workflow run that produced it.

You can verify any release asset before you enable the plugin:

gh attestation verify main.js --repo lossless-group/metafetch

If the file came out of a legitimate build of the source repo, the command exits 0 and tells you which workflow run produced it. If anything's been tampered with mid-flight — a compromised CDN, a maliciously-edited release attachment — the verification fails.

This is the same security primitive GitHub uses for its own first-party tooling. It costs you nothing to verify and gives you a real answer to "do I trust this install?"

What it changes for users

Installing from inside Obsidian: nothing. The Community Plugins directory pulls the latest release assets the same way it always has. The attestations sit alongside the release as metadata, unobtrusive.

Installing manually or auditing what's in your vault: you can now verify before you copy files in. Drop the three release assets into a folder, run gh attestation verify against each, then move them into .obsidian/plugins/metafetch/ only after the cryptographic check passes.

For the curious: each verify run tells you which GitHub Actions workflow run built the asset, when, from which commit. Provenance trail is fully reconstructible.

A note about vault enumeration

The Obsidian Community Plugins scorecard surfaces a recommendation: "Vault Enumeration: This plugin reads the full list of markdown files in your vault." That's accurate, and it's by design — the Batch Fetch command walks markdown files in the vault to find the ones with a url: frontmatter field, so it knows which notes to process. The enumeration happens only when you explicitly run the batch command, never on plugin load or as a background activity. The single-file Fetch Open Graph Data command doesn't enumerate at all — it operates on the active note only.

How the build pipeline works now

A GitHub Actions workflow (.github/workflows/release.yml) fires on every 3-digit-semver tag push. In a clean Ubuntu runner it:

1. Checks out the tagged commit

2. Installs dependencies via pnpm (frozen lockfile)

3. Builds main.js + styles.css via the same pnpm build you'd run locally

4. Signs the three release assets via actions/attest-build-provenance@v1, which uses OIDC + sigstore to bind each file to the workflow run that produced it

5. Creates the GitHub Release with the three core assets attached and the marketing copy pulled from release-notes/<tag>.md in the repo

Result: provenance is enforced by infrastructure, not by maintainer discipline. Manual gh release create from a developer's local machine is no longer the path — every release goes through the workflow.

The Lossless Group plugin family

Metafetch sits alongside three sibling plugins, all by The Lossless Group:

If Metafetch (or any of the family) saves you time, buy us a coffee. The plugins are free; the coffee keeps the next one coming.

Under the hood — what shipped in this commit

• Added .github/workflows/release.yml — the build-attest-release workflow described above

• Added release-notes/0.1.6.md (this file) — the convention going forward: each release's marketing copy lives in the repo at this path before the tag is pushed, so the workflow can pick it up. Per the marketing-doctrine codified in content-farm/context-v/skills/changelog-conventions/SKILL.md "These are marketing artifacts, not internal documentation."

• Version bumped 0.1.5 → 0.1.6 across manifest.json, package.json, versions.json

• No source-code changes — the vault-enumeration behavior the scorecard surfaces is the existing Batch Fetch implementation, called only when the user invokes the batch command