How Signed Updates Work - PattonWebz 🔗 **Source:** [How Signed Updates Work - PattonWebz](https://www.pattonwebz.com/security/how-signed-updates-work/) > [!note]+ Document Notes > tags: [signed-updates, wordpress-security, supply-chain-security, cryptographic-signing, plugin-updates] > author: William Patton > source: PattonWebz > reference: https://www.pattonwebz.com/security/how-signed-updates-work/ > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: How Signed Updates Work > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ## 📝 Summary - Most WordPress plugins sold outside the official repository update via a simple fetch-and-swap: the site checks a store, downloads a zip, replaces the old folder. The store itself is the only thing standing between an attacker and every site running the plugin. - Signed updates remove the store from the trust chain. A private key signs the zip at build time; the plugin's own code checks that signature against a bundled public key before installing anything. - GravityKit is cited as an early WordPress plugin shop to implement real signature verification for this reason. - Key stakeholders: plugin authors/build systems (hold the private key and sign), plugin stores (become pure distribution, no longer a trust anchor), site owners (the receiver/verifier), and — implicitly — attackers targeting store accounts or build pipelines as the new highest-value target. - Risks and tradeoffs it doesn't cover: a compromised build system, a site that silently stops checking for updates, non-update infection paths (compromised admin, uploaded malicious files), and the fact that a valid signature only proves authorship — not that the code is safe or bug-free. - Bottom line: signing closes exactly one door — a compromised store handing out bad files — and leaves every other attack surface where it was. ## 📖 Main Content The article frames the WordPress plugin update problem as a trust-placement problem, not a cryptography problem first. In the default model (store checks → zip download → folder swap), trust sits entirely in "has this store account been compromised?" — an operational question the site owner has no way to verify at update time. Signed updates restructure this into three independent roles: - **Build system**: builds the zip and signs it immediately, in the same CI run, before the store ever sees it. Signing becomes a pipeline step, not a manual task a human can skip or forget. - **Distribution (the store)**: hands over the zip and its signature. It doesn't need to be trusted to have built anything correctly — it's just a courier. Anyone, not just the customer's site, can fetch the pair and verify it independently. - **Receiver (the plugin's own code)**: checks the signature against a public key baked into its source before allowing an install. The core mechanism is asymmetric-key signing: a private key (author-only) signs, a public key (shipped in the plugin itself) verifies. A valid signature proves "whoever holds the private key produced this exact file" — nothing more. The article addresses the obvious follow-up (what if the private key leaks?) with a transparency-log pattern: a public, append-only log such as Rekor records every signature the moment it's created. A signature that was never logged, or one that appears out of step with a project's real release history, becomes detectable after the fact — this doesn't prevent a stolen-key signature, but it makes it discoverable. A second mechanism, the **ratchet**, defends against a different attack: replaying an old, validly-signed release (e.g., one with a known vulnerability) as a fake "update" to downgrade a site. The plugin remembers the highest version it has ever installed and refuses anything lower, even if that lower version's signature checks out fine. The piece is explicit about scope-limiting itself in its closing section: signing proves authorship of a specific file, not code safety; it doesn't secure every path a file can take onto a site (e.g., manual upload, compromised admin); it doesn't protect against a compromised build system (key revocation is separate, unbuilt machinery); it doesn't force a site to keep checking for updates at all (silent update-starvation leaves an old, correctly-signed version in place indefinitely with no invalid-signature event to notice); and the ratchet only defends against a compromised *store*, not a fully compromised *site*. ### 🗒️ Notes - Default plugin-store update flow = zip fetch + folder swap; the store account is the entire trust boundary. Compromise the store account, compromise every installed site. - GravityKit named as an early adopter of real signature verification in the WordPress plugin-shop space — used as the concrete example throughout. - Three-role split (build / distribute / receive) is the article's central organizing idea — most of what follows is really about how these three roles interact at their seams. - Key pair basics: private key signs (author-only), public key verifies (shipped inside the plugin's own source, so the site doesn't need to fetch it from anywhere untrusted at verify time). - Stolen-key mitigation isn't prevention — it's detection via a public append-only transparency log (Rekor named specifically). A signature with no log entry, or one that breaks the expected release timeline, is a tell. - Signing happens "in the same CI run" as the build, before the store ever touches the artifact — this is presented as a deliberate design choice (can't be forgotten as a separate manual step) rather than an incidental detail. - The store's job shrinks to pure delivery of (zip, signature) — verifiable by any third party independent of the store's trustworthiness. - Ratchet = monotonic version enforcement on the receiving plugin: refuses anything below the highest version ever verified/installed, closing the "downgrade to a validly-signed vulnerable version" attack. - Explicit non-goals stated by the author (deliberately, in a dedicated closing section): file safety/bug-freeness, non-update infection vectors, build-system compromise, opt-out/stalled update checking, and site-level (not just store-level) compromise. - Overall framing device: "narrows down what you have to trust" rather than "removes the need to trust anything" — the article resists overselling the mechanism. ## 📚 References - [GravityKit](https://www.gravitykit.com/) — cited as an early WordPress plugin shop implementing signed-update verification - [Rekor](https://docs.sigstore.dev/logging/overview/) — public append-only transparency log referenced for detecting stolen-key signatures - [PattonWebz — Security category](https://www.pattonwebz.com/security/) — publisher's broader security coverage ## 🗣️ Paraphrase Right now, most premium WordPress plugins trust the store they're bought from — the site just downloads whatever zip the store account currently offers, no questions asked. That's fine until someone breaks into the store account itself, at which point every customer site becomes an unwitting installer for whatever the attacker uploads. Signed updates fix this by moving trust out of the store and into the moment of the build. A private key signs the finished zip the instant it's built, before the store ever sees it; the plugin itself carries a matching public key and refuses to install anything that doesn't check out. The store becomes a dumb pipe — useful, but no longer something you have to trust. A public log catches the edge case of a stolen signing key, and a "ratchet" stops attackers from replaying an old, legitimately-signed-but-vulnerable version as a fake update. None of this makes the plugin bug-free, secures the build system itself, or forces a site to keep checking for updates — it closes one specific door and is honest about leaving the rest open. ## 📰 Newsletter Ever wonder what actually stops a compromised plugin store from quietly shipping malware to your site's next "update"? William Patton's latest breaks down **signed updates** — the mechanism GravityKit was an early adopter of — in plain, no-hype terms. The short version: instead of trusting the store, your site checks a cryptographic signature created the moment the plugin was built, plus a neat "ratchet" trick that blocks downgrade attacks to old vulnerable versions. It's a great read if you build or maintain premium plugins outside the .org repo, or just want to understand what "supply-chain security" actually buys you (and, just as usefully, what it doesn't). 🔐 ## ✅ Action Items #### DevRel - Developer experience: if writing docs/SDKs for a plugin shop's update mechanism, model the three-role split (build/distribute/receive) explicitly — it's the clearest mental model the article offers for explaining signed updates to a plugin-author audience. #### OSPO - Security Management: use this article's build→sign→distribute→verify→ratchet pipeline as a reference shape when drafting or reviewing an org's own release-signing policy, including explicit key-revocation and compromised-build-system runbooks (called out as missing "for free"). #### Community - Maintainers: worth a governance-clinic discussion for premium/outside-repo plugin shops — what would it take to standardize signed updates the way GravityKit has, and is a shared transparency-log convention (Rekor or similar) realistic across shops? #### WordPress - Plugins: relevant to review-throughput and provenance-check conversations for plugins distributed outside the .org repository, where the standard SVN-based trust model doesn't apply. ## 🧪 Hypotheses - H1: WordPress sites running plugins from stores without signed updates are more likely to receive a malicious update after a store account compromise than sites running signature-verified plugins. - H2: A public append-only signature log (e.g., Rekor) reduces the average time-to-detection of a stolen-signing-key incident compared to shops with no such log. - H3: Plugins implementing update-ratchet logic experience fewer successful downgrade-to-known-CVE attacks than plugins without version-monotonicity checks. - H4: Sites that silently stop checking for plugin updates (due to error, misconfiguration, or attacker interference) remain on outdated-but-validly-signed versions for measurably longer than actively-checking sites, independent of whether signing is present. - H5: Plugin shops that adopt signed updates see no meaningful change in *non-update* compromise vectors (e.g., stolen admin credentials, vulnerable upload endpoints), since signing doesn't address those paths. ### 📊 Methodology - H1/H3: Retrospective incident analysis across a sample of known WordPress plugin-store compromises and CVE-downgrade attacks, comparing outcomes for signed vs. unsigned plugin populations (would require cooperation from plugin shops for update-log data). - H2: Controlled comparison of mean detection time for a set of simulated or historical key-compromise events, with and without a transparency-log integration. - H4: Telemetry study (opt-in) tracking update-check frequency and installed-version staleness across a plugin's install base, correlated with the presence/absence of signature verification. - H5: Compromise-vector classification across incident reports pre- and post- a plugin shop's adoption of signed updates, to isolate whether the attack surface shifted rather than shrank. ### ❓ Questions - Does GravityKit's implementation actually integrate a Rekor-style public log today, or is that presented as a best-practice option rather than something currently deployed? - What's the actual revocation workflow when a private signing key is confirmed stolen — how fast can a shop get every install off the compromised key in practice? - How does the ratchet interact with legitimate downgrades (e.g., a customer intentionally reverting after a bad release)? Is there an override path, and how is *that* authenticated? - Who else in the WordPress plugin-shop space (Easy Digital Downloads-based sellers, other update frameworks) has adopted anything comparable, and is there a shared standard forming or is each shop building this independently? ### 🔮 Future Research - A survey of signed-update adoption across the top N premium WordPress plugin shops, benchmarked against this article's three-role model. - Case study of an actual stolen-signing-key incident (in any software ecosystem) to evaluate how well a Rekor-style log performed in practice versus in theory. - Investigation into standardizing a shared, cross-shop transparency log for WordPress plugin signatures, similar to Certificate Transparency for TLS. ### 💡 Implications - **Practice**: plugin shops distributing outside wordpress.org should treat build-time signing as a baseline control, not a differentiator — the article positions it as increasingly necessary as supply-chain attacks become more common, not optional hardening. - **Policy**: any WordPress-ecosystem discussion of "plugin security requirements" for non-.org distribution should distinguish store compromise (solved by signing) from build-system compromise and site-level compromise (not solved by signing) rather than treating "signed" as a single security checkbox. - **Security**: teams building or auditing plugin update mechanisms should explicitly test for downgrade attacks (ratchet bypass) and update-starvation (silent stop-checking), since both are called out as live, unaddressed gaps even in a signed system. - **Education**: the three-role framing (build/distribute/receive) is a strong teaching device for explaining supply-chain trust generally, not just for WordPress — reusable for developer education beyond this specific ecosystem. - **Funding models**: nothing in the article discusses cost, but implementing CI-integrated signing, key management, and a transparency log is nontrivial infrastructure — likely a barrier for smaller independent plugin authors relative to well-resourced shops like GravityKit. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid Grade ≈ 10–11 (technical vocabulary — "asymmetric key pair," "append-only log," "ratchet" — offset by short sentences and a conversational, second-person-adjacent tone). #### 👀 Visual learners - Present: none — no diagrams, screenshots, or labeled figures accompany the three-role model or the build→sign→distribute→verify pipeline despite both being highly diagrammable. - Improve: a simple sequence diagram (build system → sign → store → site → verify → install/refuse) and a keys diagram (private key holder vs. public key location) would substantially help retention. #### 🔊 Aural learners - Present: none — text only. - Improve: a 3–5 minute narrated walkthrough of the "what if the private key gets stolen" scenario would suit this audience, since it's the article's most conceptually dense section. #### 🗣️ Verbal learners - Present: strong — the article leans on plain-language analogy already ("the store is just a courier," "trust no longer lives in the store, it lives in the build system"). - Improve: a short glossary callout for "ratchet," "transparency log," and "asymmetric key pair" would help readers newer to cryptographic concepts. #### 🧩 Kinesthetic learners - Present: none — no hands-on exercise, sandbox, or reproducible example. - Improve: a small worked example (e.g., generate a keypair, sign a dummy zip, verify it) would turn the abstract mechanism into something a plugin developer could actually try. #### 🧠 Logical learners - Present: strong — the article is structurally logical (three roles → the seams between them → what it buys you → what it doesn't), which suits this learning style well as-is. - Improve: a small comparison table (Unsigned vs. Signed vs. Signed+Ratchet, mapped against attack types each defends against) would make the causal structure even more explicit. #### 🧑‍🤝‍🧑 Social learners - Present: none — no comment thread engagement or discussion prompt visible in the scraped content (a comment form exists on the page but is empty). - Improve: an explicit discussion prompt (e.g., "has your plugin shop considered this — what's stopping you?") could seed the existing comment section. #### 🧘‍♀️ Solitary learners - Present: moderate — the closing "what this doesn't secure" section functions as a natural self-check ("do I understand the boundary of what signing protects?"). - Improve: a short self-quiz ("name three things signing does NOT protect against") would reinforce the article's own scope-limiting message. #### 🌿 Naturalistic learners - Present: none — no ecosystem/lifecycle framing. - Improve: could tie the "ratchet" concept to biological/ecological analogues of one-way gates, or frame key-compromise response as an "immune system" (detect → contain → revoke) to aid retention. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: clear heading hierarchy in the source article (H1 title, then flowing prose); no obvious ARIA misuse in the scraped content. - Improve: cannot verify alt text or landmark regions from the text-only scrape provided — a live audit of the rendered page would be needed. #### Keyboard navigation - Present: not assessable from scraped content. - Improve: verify skip-links and focus order on the live page, particularly around the comment form. #### Contrast and readability - Present: not assessable from scraped content (no styling information available). - Improve: verify body text meets 4.5:1 contrast on the live PattonWebz theme. #### Text resizing and reflow - Present: not assessable from scraped content. - Improve: verify at 200% zoom on the live page, particularly for any inline code formatting. #### Media and captions - Present: no images, audio, or video in this article — no captioning need. - Improve: n/a. #### Forms and interactions - Present: standard WordPress comment form (Name, Email, Website, Comment) visible in scraped content. - Improve: verify labels are programmatically associated and error states are announced — not assessable from text scrape alone. #### Standards reference - Given the text-only nature of this scrape, only content-structure criteria (WCAG 1.3.1 Info and Relationships, via heading order) are assessable; a live-page audit is needed for 1.4.3 (contrast), 2.1.1 (keyboard), and 2.4.7 (focus visible). ### 🌍 DEIB Assessment #### Cultural breadth - Present: none notable — the article is ecosystem-neutral (general cryptographic concepts applied to WordPress), with no regional or cultural framing either way. - Improve: not a meaningful gap for this technical topic; low priority. #### Inclusive language - Present: gender-neutral throughout ("whoever holds the private key," "your site," "an attacker") — no exclusionary phrasing found. - Improve: none needed. #### Neurodiversity support - Present: short paragraphs, consistent section pattern (mechanism → seam → what could go wrong), which aids predictability. - Improve: a glossary or consistent bolding convention for first-use technical terms (ratchet, transparency log, asymmetric key) would help chunking further. #### Representation - Present: single named company example (GravityKit) and one named author; no individuals represented beyond that. - Improve: n/a — not a representation-relevant piece. #### Psychological safety - Present: measured, non-alarmist tone even when discussing attacks and compromise scenarios ("none of that makes signing pointless"). - Improve: none needed — the piece already avoids fear-based framing. ### ✅ Logical Validity #### Strong reasoning - **Causal reasoning**, "The trust no longer lives in the store. It lives in the build system, at the moment the zip is signed": this correctly locates the trust anchor by tracing exactly which party's compromise would defeat the mechanism (the build system, not the store) — a well-supported causal claim given the preceding explanation of how verification works independent of the store. - **Deductive structure** in the "what this doesn't secure" section: each limitation is derived directly from what the signature mechanically proves ("a signature only proves X, not Y"), rather than asserted independently — this is a clean deductive chain from definition to scope limit. #### Fallacies - No significant fallacies identified. The article is notably careful to avoid overclaiming — it explicitly forecloses the "silver bullet" framing a lesser piece on this topic might fall into ("None of that makes signing pointless; it just means it closes one specific door"). #### Tone of voice - Measured, technically confident, second-person-adjacent ("your site," "your plugins folder"). Avoids hype language and explicitly hedges its own claims in the closing section — a notably restrained tone for a security-marketing-adjacent topic. ### 🛡️ DARVO Analysis - **Deny**: not applicable — the article is explanatory, not a response to an accusation. - **Attack**: not applicable — no accuser or critic is being addressed or undermined. - **Reverse victim/offender**: not applicable — no victim/offender framing exists in the piece. - No DARVO pattern present. This is a technical explainer, not a defensive or reputational piece; the closing "what this doesn't secure" section is the opposite of DARVO behavior — it's a voluntary, unprompted limitation of the author's own claim. ## 🎯 Conclusion Signed updates don't make a WordPress plugin trustworthy in some absolute sense — they remove one specific, high-value attack surface (a compromised store account pushing malicious files) by moving the trust anchor to the moment of build-signing, verified independently by the plugin itself. GravityKit's implementation is offered as a concrete existence proof that this is practical today, not just theoretical. Practical next steps for readers: if you run a WordPress site on plugins from outside the official repository, ask whether your plugin vendor signs updates and logs those signatures publicly; if you build or sell plugins that way, treat this article's build→sign→distribute→verify→ratchet pipeline as a minimum-viable reference architecture — and pair it with real key-revocation and update-check-monitoring plans, since the article is explicit that signing alone doesn't cover either. ## 🔄 Refactor Appendix — How Signed Updates Work > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### Signing moves trust from store to build system > [!quote] > "The trust no longer lives in the store. It lives in the build system, at the moment the zip is signed." **Context & use**: - Main Content, "The three parts of a signed update" section - Core reframe of the whole article — every downstream mechanism (keys, Rekor, ratchet) exists to support this one claim **Tags**: #xref **Highlight**: n/a (no Reader source — direct article scrape) <!-- atomicity: 1 idea ✓ --> #### Public log detects, doesn't prevent, stolen-key signing > [!quote] > "A signature nobody logged, or a sudden new signature that shows up out of step with the real release history, is detectable." **Context & use**: - Main Content, "The keys" section - Important nuance: Rekor-style logging is a detection control, not a prevention control — easy to conflate the two **Tags**: #xref **Highlight**: n/a (no Reader source — direct article scrape) <!-- atomicity: 1 idea ✓ --> #### Ratchet blocks downgrade to old signed vulnerable version > [!quote] > "The software remembers the highest version it's ever verified and installed, and refuses to accept anything older than that. Even if that older version is validly signed." **Context & use**: - Main Content, "Verifying — and the ratchet" section - Answers a question a reader would likely have right after learning signatures alone are checked: "couldn't I just replay an old signed file?" **Tags**: #xref **Highlight**: n/a (no Reader source — direct article scrape) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### Security controls narrow trust, they don't eliminate it **Claim** (one sentence, Courtney's voice): A security control that removes one party from the trust chain (like signed updates removing the store) still leaves every other trust dependency — the build system, the site's own update-checking behavior, the code's correctness — exactly where it was. **Evidence pointer**: [[Signing moves trust from store to build system]] **Scope & conditions**: Holds for any "verify the artifact, not the distributor" pattern (package signing, container image signing, SBOM attestation); breaks down as a *complete* mental model only if someone mistakes "signed" for "safe." **Links** (≥1 with annotation): - [[Supply-chain-security]] — because extends the general principle that trust anchors should sit as close to creation as possible - [[Software-update-mechanisms]] — because applies-in any auto-update system, not just WordPress <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Check whether GravityKit's signed-update implementation actually publishes to a Rekor-style log today, or whether that's the article's forward-looking recommendation rather than current practice — https://www.pattonwebz.com/security/how-signed-updates-work/ #xref - [F2] Article idea: survey other premium WordPress plugin shops (Easy Digital Downloads-based sellers, etc.) for signed-update adoption and compare approaches #articleseed ### → Things 3 (max 2 actions) - [ ] Look up whether any WordPress-ecosystem standard or working group exists for plugin update signing (beyond individual shops like GravityKit) — research #things <!-- deep-read:sections end -->