feat: pin #sha256= on catalog downloads and verify all plugins against OpenWA 0.20.0 - #104
Merged
Merged
Conversation
…t OpenWA 0.20.0 OpenWA 0.20.0 refuses a plugin install from a URL in production unless the URL carries a #sha256=<64 hex> content pin, and the dashboard installs straight from the catalog's download link, so every catalog entry shipped an install a production host now rejects. catalog.mjs now builds each plugin and pins the artifact digest into the download URL (the build is byte-deterministic, verified against a published release asset), and the release workflow compares the built artifact against the pin before creating the Release, so a diverging build fails loudly instead of shipping a pin that can never verify. All ten plugins cut a PATCH release carrying testedOpenWAVersion 0.20.0; no plugin code changed, since the 0.20.0 breaking changes do not reach the plugin runtime. Verified against a running 0.20.0 host: install, config, enable and hook registration for all ten, a signed ingress delivery through verify, dedup, enqueue and worker dispatch, and pinned install-url and update under the production pin requirement. after-hours 0.2.3 · chat-flow 1.1.4 · chatwoot-adapter 0.9.3 · faq-bot 0.2.3 · group-translate 1.3.3 · gsheets-logger 0.3.5 · http-action 0.2.4 · supabase-otp-hook 0.3.2 · typebot-connector 0.2.4 · voice-transcription 1.2.5
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
OpenWA 0.20.0 makes a plugin install from a URL fail closed in production unless the URL carries a
#sha256=<64 hex>content pin. The dashboard installs straight from the catalog'sdownloadlink, so every catalog entry shipped an install that a production host now refuses. This pins the catalog and cuts the releases that carry it.The catalog now publishes pinned URLs.
catalog.mjsbuilds each plugin throughpackage.mjsand pins the artifact digest into thedownloadURL. The build is byte-deterministic (a local build ofgsheets-logger0.3.4 hashes identically to its published release asset), so the digest computed at catalog time is the digest the release will attach.catalog:checkregenerates from a fresh build, which makes a stale pin a hard failure instead of a silently wrong one.The release path guards the pin. After building the artifact, the workflow compares its digest against the catalog's pin and fails before the Release is created if they disagree, so a build that diverges from the catalog tree never publishes a pin that cannot verify. The release notes now tell URL installs to append the digest the same notes print.
All ten plugins cut a PATCH release.
testedOpenWAVersionmoves 0.19.0 → 0.20.0 across the catalog; no plugin code changed, because none of the 0.20.0 breaking changes reach the plugin runtime: the loader, sandbox, manifest validation and capability surface are untouched between the tags, and the pin requirement lives in the download funnel. Pinned URLs are backward compatible: 0.19.0 already parsed and verified the fragment, so older hosts gain the verification rather than a rejection.Compatibility was verified against a running 0.20.0 host, not just the tags: all ten plugins install, take config, enable and register their hooks;
supabase-otp-hookreceives a signed ingress delivery through the full verify, dedup, enqueue and worker-dispatch path; and pinned install-url and update both succeed underPLUGIN_INSTALL_REQUIRE_PIN=true, while unpinned and wrongly pinned URLs are rejected. The vendored contract header records the 0.20.0 alignment: the diff over the six vendored host files is empty.Verification
catalog:check), all ten bundles build and pass the loader contract.Release
Ten tags, each pushed on its own so its release run triggers:
after-hours-v0.2.3,chat-flow-v1.1.4,chatwoot-adapter-v0.9.3,faq-bot-v0.2.3,group-translate-v1.3.3,gsheets-logger-v0.3.5,http-action-v0.2.4,supabase-otp-hook-v0.3.2,typebot-connector-v0.2.4,voice-transcription-v1.2.5. Push the tags before merging so the pinned URLs resolve from the moment the catalog goes live onmain.