I committed a new version of my plugin to SVN and got a message I hadn’t seen before: this version will reach sites in about 24 hours. My first tho...
For further actions, you may consider blocking this person and/or reporting abuse
The most dangerous attacks are often the ones that follow every rule.
No stolen accounts. No zero-days. No infrastructure compromise. Just a legitimate ownership transfer followed by a legitimate release process.
That’s why modern security isn’t about trusting people more carefully. It’s about designing systems that remain safe even when trusted actors change. The 24-hour review window is less about malware detection and more about acknowledging that trust itself is a mutable asset.
Exactly. "Trust as a mutable asset" is a sharper way to put what I was circling around. The part that stayed with me is that the only place to act on that mutability is the gate, not the actor. You can't ask an actor to flag the moment their own trust changed hands, so you stop trusting the actor and verify the artifact instead.
That’s a great point.
What strikes me is that mature systems eventually stop asking “Who produced this?” and start asking “What evidence do we have that this is safe?” Identity remains important, but it’s no longer sufficient. The more valuable the supply chain becomes, the more verification shifts from actor-based trust to artifact-based trust.
That's the shift, yeah. "What evidence do we have that this is safe?" is exactly where I landed, and it's why I can sit with my own commits being held. I trust myself the least usefully of anyone, a self-review once surfaced 35 issues I'd written, so artifact-based verification checking me too feels right, not insulting. Identity gets you in the door; the evidence is what actually ships.
“Identity gets you in the door; evidence is what ships” is probably the best summary of modern security I’ve heard in a while.The interesting part is that this principle scales remarkably well. Whether the producer is a maintainer, a vendor, an employee, or an AI model, the question eventually converges to the same thing:
What evidence do we have that this artifact is safe?
That's the shift, yeah. "What evidence do we have that this is safe?" is exactly where I landed, and it's why I can sit with my own commits being held. I trust myself the least usefully of anyone, a self-review once surfaced 35 issues I'd written, so artifact-based verification checking me too feels right, not insulting. Identity gets you in the door; the evidence is what actually ships.
Default distrust feels annoying until you remember how much supply-chain trust is sitting behind a plugin update. For ecosystems like WordPress, the commit path is effectively a distribution channel, not just source control.
The healthy version is not "make every author suffer"; it is making provenance and review visible enough that maintainers can prove a release deserves trust. Friction is acceptable when it protects users from invisible compromise.
You sharpened the part I left implicit. The commit path being a distribution channel and not just source control is the whole reason the old "committer is trusted" assumption was load-bearing in a place nobody was looking.
And your reframe is the one I'd adopt: the healthy version isn't punishing authors, it's making provenance and review visible enough that a release can prove it deserves trust. That flips the default from "trust me" to "here's why this is verifiable," which is a better place for everyone to stand, me included. Distrust-by-default is only the blunt first move. Provability is the part that makes the friction worth paying, because friction that just slows everyone down is a tax, while friction that surfaces provenance is protection. The trick is keeping it the second kind.
That release-channel framing is the key. Once a commit path can ship to users, trust needs proof, not vibes. Provenance and review metadata are annoying until they prevent a compromised release from looking like ordinary maintenance.
"Trust needs proof, not vibes" is the line I'll be quoting back. That's the whole shift compressed: the moment a commit path can reach users, the author's word stops being enough, because the word is exactly what an attacker buys.
And your last point is the one that makes the friction worth it. Provenance and review metadata feel like pure overhead right up until the day they stop a compromised release from passing as ordinary maintenance, which is precisely how the April attack worked. A malicious update that looks like a routine patch is the thing the metadata exists to catch. Annoying until it isn't, and the day it isn't, it's the only thing standing there. Good exchange.
As someone who maintains open source tools, I had the same initial reaction; slower updates feel like a regression. But after thinking about it, the 24-hour hold is a reasonable tradeoff. The backdoor incidents this year proved that the old model of "commit and deploy instantly" assumed goodwill that doesn't hold at scale. I'd rather have a frustrated maintainer than 400,000 compromised sites. Plausible next step: signed commits required?
"Assumed goodwill that doesn't hold at scale" is the cleanest one-line version of what broke. The instant-deploy model wasn't naive, it just priced in trust that worked until commit access became something you could buy.
On signed commits: I think they're a likely next step, but worth being clear about what they fix and what they don't. Signing proves a commit came from the key it claims, which is real value against a hijacked account. The April incident is the harder case, because the attackers held the legitimate keys, they bought them. A signed commit from a purchased author is still a valid signature. So signing raises the floor, it doesn't replace the review layer, it strengthens the provenance half while the 24-hour check still has to cover the "legitimate author, malicious release" case. Both, not either. Identity you can verify, plus a release you can inspect.
This feels less like a delay and more like a maturity shift: trust is moving from “who committed this” to “did this change earn delivery.” That is a much healthier default for any software supply chain.
"Did this change earn delivery" is a better line than anything in the post. That's the whole shift in five words: trust moving from the identity of the committer to the merit of the change. Identity was always a proxy, and it held right up until identity itself could be bought. Judging the change instead of the person is the default that doesn't break when the person turns out not to be who you trusted.
That’s pretty concerning — it sounds like WordPress is now enforcing stricter commit validation or certificate checks, maybe related to HTTPS or signed commits. I’ve seen similar issues with Git hooks and CI pipelines when infrastructure keys are rotated or misconfigured. Have you checked if your SSH key or SVN client config needs an update? It’s a good move from a security standpoint, but the error message could be more helpful.
Appreciate the security take at the end, that's actually the whole point of the post. One clarification though: this wasn't an error on my end or a key/config issue to fix. Nothing broke. WordPress.org deliberately changed the default so that a committer's identity no longer implies the commit should be trusted, and the post is me arguing that's the right call, not a problem report.
So there's nothing to update on my side, and that's by design. The shift is from "trusted because we know who pushed it" to "verified because the change itself was reviewed," which holds even when the author's credentials are perfectly valid. A signed commit from a compromised or purchased account is still a valid signature, which is exactly why identity alone stopped being enough. I do agree the messaging around it could be clearer, that part you're right about.