Previously, I wrote about how code-signing and threshold signatures could allow the WordPress community (whether they continue to support WordPress or decide to hard-fork the project onto something else) to mitigate the risk of another Mullenweg tantrum (which are in surplus this season) leading to another successful violation of community trust.

One reason why the community might not want to do a hard-fork is that it could be disruptive to the entire WordPress Developer job title. Namely, it would make plugin and theme development and maintenance painful to support both WordPress and whatever the fork is named.

But that’s not actually a significant technical hurdle.

Because WordPress (and, by extension, its plugin and theme ecosystem) is copyleft licensed, the Forkers could easily write some infrastructure involving Rector (or a more specialized fork of Rector, heh) to plumb plugin/theme updates into the forked ecosystem.

That is to say, because of the existing work into helping open source software support wider ranges of PHP versions, I believe the “supporting WordPress and ForkPress” is not a significant technical challenge.

Additionally, if the ForkPress leadership sets up the plumbing to make this happen, the existing WordPress developers the world over won’t need to lift a finger to make it happen. (And since it’s all copyleft, they’re already licensed to do so, provided the output of their code transpiler is similarly licensed.)

There would still be some friction, naturally.

If the people leading a hypothetical WordPress fork actually heed my advice about making code-signing ubiquitous (and controlled by the developers of each plugin and theme), there would need to be an identity verification and hand-off process for the third-party developers to decide, “Instead of ForkPressAutoTranspileBot, I should be the one to ship this code and sign releases.”

Doing this hand-off on a first-come, first-serve basis would be a nightmare for the forked ecosystem.

We would need a way to make key management easy and secure, even for developers who don’t live in privileged countries with booming economies. As fun as it would be to say, “FIDO2 Tokens or Bust,” that’s prohibitive to many, and we need to be conscientious about those challenges.

But the one thing we have the technology to prevent today is forcing plugin/theme developers to write two different versions of their code to manage different APIs that follow different naming conventions. In that regard, it could be made painless (but not frictionless).

If Matt Mullenweg decided to be intentionally disruptive to these forks, it would require making drastic changes to the WordPress core that breaks compatibility with all existing plugins and then using some legal mechanism to prevent the forked code from following suit (which the GPL enables the fork to do). Not only would it be stupid to try that, it wouldn’t accomplish anything productive.

But, okay, so what? We can guarantee plugin/theme compatibility in a fork. What does that give us?

First, it gives the fork free reign to make breaking API changes (i.e., to remove any trademarks from the source code and avoid legal peril from Automattic), which matters for non-technical reasons.

But it also allows the fork to use “newer” PHP language features (i.e., namespaces). And new plugins can be written for modern PHP then transpiled to support WordPress’s norms.

As cool as that is, there is still an open problem to the plugin ecosystem.

And it’s not a new problem, by any means.

But since I promised I have ideas for security enhancements, I’d like to offer this one to the community to chew on.

Who Sources Your Source Code?

Code-signing addresses supply-chain custody problems: Did the software come from the person that it should have? It doesn’t solve the problem of, “What if the developer of a plugin or popular theme goes rogue and ships crypto-miners?”

When I proposed Gossamer, I specified Third-Party Attestations as a building block for building defenses against this sort of attack. That certainly could be useful for WordPress (or a fork thereof): Require a third party to at least spot check the code changes from the previous release to make sure nothing deliberately malicious was shipped.

Another idea I’d like to propose is to perform a differential analysis of the cyclomatic complexities of each unit of PHP and/or JavaScript code.

I probably lost some of you, so I will elaborate.

For each release of a plugin or theme:

1. Use a library like sebastian/complexity (PHP) or cyclomatic-complexity (JS) to estimate the complexity of every unit of code within a codebase.
2. Store these snapshots alongside each release.

When a new release is proposed, compare the new code release with the previous one.

Large differences in the structure of the code should be flagged for manual review (especially if it’s only a minor version bump or patch release).

Additionally, compare the current snapshot with the last version that was marked as manually reviewed. If each piecemeal change was small, but there was a lot of them, it may add up to warrant additional third-party scrutiny.

This isn’t entirely novel. In fact, this sort of work sounds right up the alley of the WordFence team to build, should they choose to embark on this task.

WordPressed For Time

I have several other ideas about ways to improve the assurance and robustness of the ecosystem, but some of them require secure code delivery (code-signing + transparency logs + reproducible builds) to already exist to be worthwhile.

In the interest of a positive and productive conversation about the future of the ecosystem that accounts for damn-near half of websites, consider the ideas shared on these pages freebies.

A better future is possible, if only we have the will to build it.

https://scottarc.blog/2024/10/14/a-wordpress-hard-fork-could-be-made-painless-for-plugin-theme-developers/

#blog #blogging #cyclomaticComplexity #digitalMarketing #softwareCompatibility #softwareSecurity #transpiling #website #WordPress

Semantically Secure

2024-10-14 07:16:20

As I write this, the most recent big move by Matt Mullenweg in his ongoing dispute with WP Engine was to abuse his position to seize control of a WP Engine owned plugin, justifying this act with a security fix. This justification might, under other circumstances, be believable. For example, if WP Engine weren’t actively releasing security fixes.

Now, as I wrote on a Hacker News thread, I’d been staying out of this drama. It wasn’t my fight, I wasn’t deeply familiar with the lore of the players involved, etc.

BUT! This specific tactic that Mullenweg employed happens to step on the toes of some underappreciated work I had done from 2016 to 2019 to try to mitigate supply chain attacks against WordPress. Thus, my HN comment about it.

Mullenweg’s behavior also calls into question the trustworthiness of WordPress not just as a hosting platform (WP.com, which hosts this website), but also the open source community (WP.org).

The vulnerability here is best demonstrated in the form of a shitpost:
“Matt” here is Mullenweg.
I do not have a crystal ball that tells me the future, so whatever happens next is uncertain and entirely determined by the will of the WordPress community.

Even before I decided it was appropriate to chime in on this topic, or had really even paid attention to it, I had been hearing rumors of a hard-fork. And that maybe the right answer, but it could be excruciating for WordPress users if that happens.

Regardless of whether a hard-fork happens (or the WordPress community shifts sufficient power away from Mullenweg and Automattic), this vulnerability cannot continue if WordPress is to continue to be a trustworthy open source project.

Since this is a cryptography-focused blog, I’d like to examine ways that the WordPress community could build governance mechanisms to mitigate the risk of one man’s ego.

Revisit Code-Signing

The core code, as well as any plugins and themes, should be signed by a secret key controlled by the developer that publishes said code. There should be a secure public key infrastructure for ensuring that it’s difficult for the infrastructure operators to surreptitiously replace a package or public key without possessing one of those secret keys.

I had previously begun work on a proposal to solve this problem for the PHP community, and in turn, WordPress. However, my solution (called Gossamer) wasn’t designed with GDPR (specifically, the Right to be Forgotten) in mind.

Today, I’m aware of SigStore, which has gotten a lot of traction with other programming language ecosystems.

Additionally, there is an ongoing proposal for an authority-free PKI for the Fediverse that appears to take GDPR into consideration (though that’s more of an analysis for lawyers than cryptography experts to debate).

I think, at the intersection of both systems, there is a way to build a secure PKI where the developer maintains the keys as part of the normal course of operation.

Break-Glass Security with FROST

However, even with code-signing where the developers own their own keys, there is always a risk of a developer going rogue, or getting totally owned up.

Ideally, we’d want to mitigate that risk without reintroducing the single point of vulnerability that exists today. And we’d want to do it without a ton of protocol complexity visible to users (above what they’d already need to accept to have secure code signing in place).

Fortunately, cryptographers already built the tool we would need: Threshold Signatures.

From RFC 9591, we could use FROST(Ed25519, SHA-512) to require a threshold quorum (say, 3) of high-trust entities (for which there would be, for example, 5) to share a piece of an Ed25519 secret key. Cryptographers often call these t-of-N (in this example, 3-of-5) thresholds. The specific values for t and N vary a lot for different threat models.

When a quorum of entities do coordinate, they can produce a signature for a valid protocol message to revoke a developer’s access to the system, thus allowing a hostile takeover. However, it’s not possible for them to coordinate without their activity being publicly visible to the entire community.

The best part about FROST(Ed25519, SHA-512) is that it doesn’t require any code changes for signature verification. It spits out a valid Ed25519 signature, which you can check with just libsodium (or sodium_compat).

Closing Thoughts

If your threat model doesn’t include leadership’s inflated ego, or the corruption of social, political, and economic power, you aren’t building trustworthy software.

Promises and intentions don’t matter here. Mechanisms do.

Whatever the WordPress community decides is their best move forward (hard forks are the nuclear option, naturally), the end result cannot be replacing one tyrant with another.

The root cause isn’t that Mullenweg is particularly evil, it’s that a large chunk of websites are beholden to only his whims (whether they realized it or not).

One can only make decisions that affects millions of lives and thousands of employees (though significantly fewer today than when this drama began) for so long before an outcome like this occurs.
Edit of XKCD
If you aren’t immune to propaganda, you aren’t immune to the corruption of power, either.

But if you architect your systems (governance and technological) to not place all this power solely in the hands of one unelected nerd, you mitigate the risk by design.

(Yes, you do invite a different set of problems, such as decision paralysis and inertia. But given WordPress’s glacial pace of minimum PHP version bumps over its lifetime, I don’t think that’s actually a new risk.)

With all that said, whatever the WordPress community decides is best for them, I’m here to help.

https://scottarc.blog/2024/10/14/trust-rules-everything-around-me/

#AdvancedCustomFields #arrogance #automaticUpdates #Automattic #codeSigning #cybersecurity #ego #MattMullenweg #news #PKI #pluginSecurity #powerCorrupts #SecureCustomFields #security #softwareGovernance #supplyChain #supplyChainSecurity #supplyChainSecurity #technology #threatModels #trust #WordPress #WPEngine