Make a bare plugin name resolve to a verified release

[scttfrdmn]

Closes #816. Advisory: GHSA-54x4-pc23-4m6j (draft; publishes on merge).
Advisory item 3 is split out as #838 — see the end.

The defect

spawn plugin install <name> — no @version — resolved to the registry's main
branch, and performed no signature check, no checksum check, and emitted no warning. A
plugin spec runs as root on the instance (pkg/pluginruntime/remote_executor.go).

The verification itself is well built and genuinely fail-closed. The problem was the
condition deciding whether it runs:

gitRef := pr.Version
if pr.Host == "official" && pr.Version != "" {   // ← bare name: false
    tag := officialTag(pr.Name, pr.Version)
    prov.ReleaseTag = tag
    gitRef = tag
}
...
if prov.ReleaseTag != "" {                        // ← so never entered
    if err := r.verifyRelease(ctx, pr, prov); err != nil { return nil, nil, err }
}

So the install form a person is most likely to type was the one that checked nothing.

The gate was not wrong when it was written. Bare-name resolution used to 404 against
the official registry layout (#448), making the path unreachable. That bug was fixed, and
fixing it quietly armed this one. Confirmed today:

$ curl -o /dev/null -w '%{http_code}' \
    https://raw.githubusercontent.com/spore-host/spore-plugins/main/plugins/tailscale/plugin.yaml
200

Fix

A bare official name resolves to the plugin's latest release tag — exactly the input
the verified path already takes. Verification is unchanged; it simply now runs. The
verified path becomes the default rather than the opt-in.

Refusals, not fallbacks:

• No releases published → refuse, pointing at --insecure. Installing an unsigned
  spec from a mutable branch should be an explicit choice.
• Releases API unreadable (403/429/5xx/404, or malformed JSON) → refuse. If a rate
  limit returned "no releases", an attacker could induce the unverified path just by
  exhausting the quota. "The API says there are none" and "we could not ask" are
  different, and only one is safe to act on.

--insecure still reaches the default branch, and now says so. The "unverified source"
warning fired only when owner != "spore-host", so the official unverified path — the one
that mattered — told the user nothing.

A trap I walked into

softFail returns nil under --insecure. My first version did
return nil, nil, r.softFail(err), which under --insecure returns a nil spec with no
error. The refusal branches now continue instead, and the tag is built only when a
version was actually resolved — otherwise officialTag("demo", "") yields the tag
demo- and fetches a ref that cannot exist.

A test that certified the vulnerability

TestResolveOfficialBare_NoManifestFetch asserted the bug was correct behaviour:

A bare official ref (no version) has no release/manifest; resolution must succeed and
must NOT mark ManifestVerified. The release server fails the test if it's ever contacted.

Accurate about the code, false about the design — and because it was written from the
code, it would have failed on the fix and argued against it. It is now
TestResolveOfficialBare_ResolvesToLatestReleaseAndVerifies, asserting the opposite, with
the reason recorded in place. That is CLAUDE.md rule 5, and this is the clearest instance
of it the audit has turned up: the test did not merely miss the gap, it defended it.

Two consequential test updates follow from the behaviour change, both made explicit rather
than quiet:

• Three provenance tests legitimately exercise the default-branch path (commit-SHA
  pinning, content hashing). They now use a named newInsecureTestResolver instead of
  inheriting the old permissive default, so it is visible that they test the --insecure
  path.
• The spec-path test's "official bare name" case asserted /main/.... It now pins the
  tagged URL, because fetching at the tag is the mechanism by which verification is
  reached — the path assertion is the thing that proves it.

Gates

On version selection, since that is the input deciding whether verification happens at
all. Six compiling reverts, each failing the intended gate:

revert	caught by
bare name falls through to the default branch	TestResolveOfficialBare_ResolvesToLatestReleaseAndVerifies — reports the main-branch URL and that the release endpoint was never contacted
API failure treated as "no releases"	TestLatestOfficialVersionReportsAPIFailuresAsErrors
lexical instead of semantic ordering	TestLatestOfficialVersionOrdersSemantically — latest = "1.9.0", want "1.10.0"
prefix no longer isolated	TestParseOfficialTagIsolatesThePluginName — demo-extra-1.2.3 read as a demo version
drafts/prereleases included	TestLatestOfficialVersionSkipsDraftsAndPrereleases
pagination not followed	TestLatestOfficialVersionFollowsPagination

The ordering one is worth dwelling on: a string compare puts 1.9.0 above 1.10.0, so a
lexical max would install an older plugin than the one published, and the install would
succeed and verify cleanly. Nothing would look wrong.

Prefix isolation matters for the same reason — install tailscale must not resolve to a
tailscale-exit-node release, which would verify the wrong artifact against the wrong
manifest and still pass.

Pagination is asserted with a genuinely full first page whose newest release is on page
two, and bounded at releaseTagsPageLimit so one install cannot become an unbounded walk.

Split out: #838

Advisory remediation item 3 — the signature covers plugin.yaml but not the artifacts the
spec downloads and runs — is not in this PR. Step.SHA256 is optional and unenforced,
but the live official plugins declare no checksums at all (tailscale: 0, spore-sync: 0),
so enforcing it here would break every official install until spore-plugins is updated.
Filed as #838 with the ordering of work.

Verification

make check (all nested modules), make check-docs, changelog gate,
semgrep scan --config=auto --error . (0 findings), make api-snapshot (no drift), Tier 0
e2e with -count=1.

Couples to #448 as the advisory notes: further work on bare-name resolution without this
would have widened the unverified path rather than closed it.

[codecov]

Codecov Report

❌ Patch coverage is 93.75000% with 5 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
pkg/plugin/latest_release.go	91.07%	3 Missing and 2 partials ⚠️

📢 Thoughts on this report? Let us know!