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>
20 lines
727 B
Plaintext
20 lines
727 B
Plaintext
# Private signing keys. NEVER commit one of these.
|
|
# The real key lives only in the INDEX_SIGNING_KEY CI secret.
|
|
*.pem
|
|
*.key
|
|
index-signing-key*
|
|
|
|
# NOTE: v1/index.json.sig IS committed -- it is the published artifact. The
|
|
# index is served from this repo's raw URLs, so the committed signature is what
|
|
# hosts fetch, and keeping it in git history makes every past signature
|
|
# independently auditable. Only CI (with the real key) should ever write it.
|
|
#
|
|
# If you sign locally to experiment, write the result somewhere clearly
|
|
# disposable so it cannot be mistaken for the real signature and committed:
|
|
# bun run sign -- --key throwaway.pem && mv v1/index.json.sig scratch.sig
|
|
*.scratch.sig
|
|
scratch.sig
|
|
|
|
node_modules/
|
|
.DS_Store
|