# How Signed Updates Work > [!question] Lingering Questions > - Does GravityKit's signed-update implementation actually publish to a Rekor-style transparency log today, or is that the article's forward-looking recommendation rather than current practice? > - Does any WordPress-ecosystem standard or working group exist for plugin update signing, beyond individual shops implementing it independently? > [!tip] Article Ideas > - Survey other premium WordPress plugin shops (Easy Digital Downloads-based sellers, etc.) for signed-update adoption and compare approaches. > [!link] Cross Reference > - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — signed updates as one layer in a broader supply-chain defense stack > - [[3. Resources/Permanent Notes/Update Signatures Prove Provenance Not Freshness]] — the Permanent note already promoted from this source in a prior pass > [!quote] Vocabulary > - **Rekor-style log** — a public, append-only transparency log that records signing events, making a stolen-key signature detectable (not preventable) because it shows up out of step with the real release history ## Bib capsule pattonwebz.com, "How Signed Updates Work," 2026 — https://www.pattonwebz.com/security/how-signed-updates-work/ ## Author's thesis (Adler Q1+Q2) 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 — meaning 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, and 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. The article's bottom line: signing closes exactly one door — a compromised store handing out bad files — and leaves every other attack surface (a compromised build system, a site that silently stops checking for updates, non-update infection paths) exactly where it was. ## Key arguments (≤3) 1. **Trust relocates to the build system, not the distributor** — the store becomes pure distribution once the signing key lives at build time. 2. **Public logging detects tampering, it doesn't prevent it** — a stolen-key signature is still cryptographically valid; a transparency log only makes it visible after the fact. 3. **A version ratchet defeats the "replay an old signed file" attack** — the client remembers the highest version it's ever verified and refuses anything older, even if validly signed. ## Claim atoms ### 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." **Where/why**: Main Content, "The three parts of a signed update." The core reframe of the whole article — every downstream mechanism (keys, Rekor, ratchet) exists to support this one claim. #xref ### 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." **Where/why**: Main Content, "The keys." Important nuance: Rekor-style logging is a detection control, not a prevention control — easy to conflate the two. #xref ### 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." **Where/why**: Main Content, "Verifying — and the ratchet." Answers the natural follow-up question after learning signatures alone are checked: couldn't I just replay an old signed file? #xref ## Permanent candidates - **Update signatures prove provenance, not freshness** — already promoted to [[3. Resources/Permanent Notes/Update Signatures Prove Provenance Not Freshness]] in a prior pass. Not re-created; connecting instead. - **Signing narrows trust to the build system, it doesn't eliminate it** — a distinct claim about what signing does and doesn't cover overall. Promoted below. ## Processing checklist - [ ] Verify GravityKit's current Rekor-style logging status vs. article's forward-looking framing - [ ] Look for a WordPress-ecosystem-wide plugin-signing standard or working group - [x] Connect into the relevant MOC — [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] ## Links - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — signed updates as one supply-chain defense layer - [[3. Resources/Permanent Notes/Update Signatures Prove Provenance Not Freshness]] — the Permanent note this source already produced - [[3. Resources/Readwise/Articles/How Signed Updates Work - PattonWebz]] — source document