Semantically Secure on Nostr: Previously, I wrote about [how code-signing and threshold signatures could allow the ...
Previously, I wrote about [how code-signing and threshold signatures could allow the WordPress community](https://scottarc.blog/2024/10/14/trust-rules-everything-around-me/ ) (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](https://ma.tt/2024/10/on-dhh/ ) this season) leading to another [successful violation of community trust](https://anderegg.ca/2024/10/13/acf-has-been-hijacked ).
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](https://github.com/rectorphp/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](https://www.php.net/manual/en/language.namespaces.php )). 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](https://gossamer.tools/ ), 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:<li>Use a library like <a href="https://github.com/sebastianbergmann/complexity"; target="_blank" rel="noreferrer noopener">sebastian/complexity</a> (PHP) or <a href="https://github.com/pilotpirxie/cyclomatic-complexity"; target="_blank" rel="noreferrer noopener">cyclomatic-complexity</a> (JS) to estimate the complexity of every unit of code within a codebase.</li><li>Store these snapshots alongside each release.</li>
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](https://www.wordfence.com/ ) team to build, should they choose to embark on this task.##
WordPressed For TimeI 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/
#cyclomaticComplexity #softwareCompatibility #softwareSecurity #transpiling #WordPress
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](https://github.com/rectorphp/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](https://www.php.net/manual/en/language.namespaces.php )). 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](https://gossamer.tools/ ), 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:<li>Use a library like <a href="https://github.com/sebastianbergmann/complexity"; target="_blank" rel="noreferrer noopener">sebastian/complexity</a> (PHP) or <a href="https://github.com/pilotpirxie/cyclomatic-complexity"; target="_blank" rel="noreferrer noopener">cyclomatic-complexity</a> (JS) to estimate the complexity of every unit of code within a codebase.</li><li>Store these snapshots alongside each release.</li>
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](https://www.wordfence.com/ ) team to build, should they choose to embark on this task.##
WordPressed For TimeI 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/
#cyclomaticComplexity #softwareCompatibility #softwareSecurity #transpiling #WordPress