enricobuehlerandClaude Fable 5
efb37d1826
The catalog the Punktfunk plugin store fetches. Served straight out of this repository over Gitea's anonymous raw endpoint: https://git.unom.io/unom/punktfunk-plugin-index/raw/branch/main/v1/index.json https://git.unom.io/unom/punktfunk-plugin-index/raw/branch/main/v1/index.json.sig Hosts verify the ed25519 signature against a compiled-in public key and only then parse. Verified that the raw endpoint serves blobs byte-for-byte, which the signature depends on; .gitattributes pins LF so a Windows checkout cannot break it from the other direction. Entries pin one exact version plus that version's registry tarball integrity hash -- no ranges, no "latest". A plugin author publishing a new version changes nothing for users; the new version becomes installable only when a reviewer works the checklist and lands a new pinned entry here. That data shape is what makes "verified on every release" enforceable rather than a promise. Seeded with the two first-party plugins, both integrity hashes confirmed against the live registry: - @punktfunk/plugin-rom-manager 0.3.1 (linux, windows) - @punktfunk/plugin-playnite 0.1.1 (windows) Tooling (bun + TypeScript, node builtins only): - validate: every field rule the host enforces, plus a live registry cross-check that the pinned version exists and its dist.integrity matches the pin. Strict on unknown keys, since the host silently drops entries that fail validation -- a `min_host` typo would otherwise ship as a missing version floor with no error anywhere. - sign / verify / keygen: ed25519 over the exact bytes of index.json. keygen never prints the private key; verify defaults to the host-pinned public key so an index can be audited with no arguments. CI splits by trust: pull requests run validate only and hold no secrets, so a fork PR can never reach the signing key or a token that can write to main. Publishing from main validates, signs, self-verifies, then commits the signature back. The loop guard is a paths-ignore filter on v1/index.json.sig, with a [skip ci] marker as a second line of defence; ed25519 determinism means an unchanged index re-signs to identical bytes and commits nothing at all. CI signs after the merge, so there is a brief window where index.json is newer than its signature. It fails closed -- hosts reject the document and keep their last good cached catalog -- and is documented as such in the README. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
44 lines
1.5 KiB
YAML
44 lines
1.5 KiB
YAML
# PR gate: validate only. NO signing, NO push, NO secrets.
|
|
#
|
|
# Pull requests can come from forks, and a fork PR must never be able to reach
|
|
# INDEX_SIGNING_KEY or a token that can write to main -- a malicious PR could
|
|
# otherwise exfiltrate the key by editing a tool or a workflow step. This job
|
|
# runs the validator and nothing else, so the worst a hostile PR can do is fail
|
|
# CI.
|
|
name: validate
|
|
run-name: validate plugin index
|
|
|
|
on:
|
|
pull_request:
|
|
workflow_dispatch:
|
|
|
|
jobs:
|
|
validate:
|
|
runs-on: ubuntu-24.04
|
|
timeout-minutes: 10
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
|
|
- uses: oven-sh/setup-bun@v2
|
|
with:
|
|
bun-version: latest
|
|
|
|
# Includes the live registry cross-check: the pinned version must exist
|
|
# upstream and its dist.integrity must match the pinned hash exactly.
|
|
# This is the check that fails a PR pinning a hash nobody verified.
|
|
- name: Validate index
|
|
run: bun run validate
|
|
|
|
- name: Reviewer reminder
|
|
if: success()
|
|
run: |
|
|
{
|
|
echo "### Automated checks passed"
|
|
echo
|
|
echo "The index is well-formed and every pinned hash matches its registry."
|
|
echo
|
|
echo "**This does not mean the plugin is safe.** The machine can only confirm"
|
|
echo "that the pinned bytes are the bytes upstream serves -- not what those"
|
|
echo "bytes do. Work the review checklist in the PR description before merging."
|
|
} >> "$GITEA_STEP_SUMMARY"
|