Git-php integration for plugins

Governance Community Feedback
,
21

So let me elaborate more on where my suggestion was coming from.

By day (at least for the past 16 years) I work in Information Security in Critical Infrastructure (energy & utilities). My background is cybersecurity, and more specifically vulnerability management.

My WordPress experience goes back quite a long ways to when I transitioned my blog at the time over to WordPress from Moveable Type when MT changed their license. I don’t remember what version of WordPress it was but I do remember that guacamole green theme that it had. (I still liked that theme.)

Anywho, I’ve been a WordPress user ever since with a Joomla site here and there for good measure.

Every day I deal with vendors and applications who either don’t plan for security updates very well, or let alone don’t have an effective process for keeping their applications updated.

As we all know every piece of software has vulnerabilities. If you don’t think your application or plugin or theme doesn’t have vulnerabilities your hubris is showing.

So when those vulnerabilities are discovered, and when vendors patch and fix those vulnerabilities, getting those updates out as quickly as possible helps reduce the risk that vulnerability will then be exploited by a malicious actor.

WordPress has done a pretty decent job with its automatic updates of plugins and theme in recent versions, but that process is far from perfect and is riddled with problems.

Every single one of my sites that had CloudFlare’s official plugin installed broke not too long ago thanks to WordPress’ automatic plugin updates.

It wasn’t WordPress’ fault, it was CloudFlare’s. But because CloudFlare updated their plugin and pushed it out WordPress gladly updated and then bricked my site.

There is no way to roll-back a bad update in the current situation.

But I don’t only just run WordPress for my personal sites.

I also run some Pleroma sites (erlang/ elixir), a personal NextCloud, prosody, PixelFed, and others.

It’s normal for me to do a git pull and pull down the latest source for pleroma when a new version is released.

And in fact I’ve had to roll-back to previous versions when I couldn’t upgrade for whatever reason.

And that’s relatively easy to do in git, too.

Not to mention I’ve been bit more than once if I accidentally modified the source code for a file in Pleroma when I would go to do another git pull that git would complain and tell me that one of my files has been modified outside of the repository.

And this seemed like a perfect example then of alerting the user that maybe a hacker had inadvertently modified something without the site owner realizing.

And I got to thinking, wouldn’t it be great if ClassicPress adopted some of those same techniques.

After all, the plugins are already required to be hosted at GitHub.

So that’s kind of what the drive was for my suggestion.

Look, whether it’s git-php or something different doesn’t really matter.

The crux of what I was suggesting was to take full advantage of everything the GitHub offers you. If you’re going to make that be a dependency (and I agree that is a logical initial step but maybe future versions would support Gitlab?) and if you’re moving towards using composer to install the cms (which is awesome by the way. PixelFed uses both composer and laravel and administering that installation is pure joy) then supporting git and all that it offers didn’t seem to be too far of stretch.

(Edit: I also wanted to add I also run my own Discourse installation too. Have you guys looked at what Discourse does for plugin management? It is freakin’ beautiful. You put the GitHub URL in the Discourse config and when you go to check for new versions, Discourse automatically downloads and installs the latest version directly from GitHub. That’s what I was originally thinking of. And, okay so it doesn’t make since with a WordPress fork to require the plugins to be specifically set in wp-config.php but the idea on the backend is what I was referring to.)

1 Like
22

That’s what CP would do, too. No extra git stuff needed.

2 Likes
23

It’s coming :+1:

I agree, if we are going to do it then we might as well do it right and take advantage of the new modern technologies.

2 Likes
24

Since git is a separate layer that basically creates a new user-space filesystem “in between” the real filesystem and the code itself, it needs to be managed as such, either via the git executable or by some custom solution developed by a full-time team of 5-10+ people. Trying to shove all of that into ClassicPress itself would be a mistake - it would add a huge amount of code with all of the accompanying slowness, complexity, edge cases and bugs. Also, since ClassicPress knows how to work with zip files for plugins already, the new plugin directory integration will need to use the zip files on GitHub, otherwise we would be looking at a delay of several more years to ship v2.

Having said that, I’m a big fan of using git to deploy CP/WP sites and monitor their filesystem security. The way that works the best for me so far is to stick the whole site (core, plugins, themes… everything except uploads) into a git repository, and manage that via SSH.

People also manage entire sites using composer which is sort of similar but probably more complicated overall.

2 Likes
25

I’m curious what the downside then would be for using git to deploy plugins and themes?

Every one of these plugins is checked for a new version by calling git to see if a new release has been published:

image
image1321×1792 149 KB

I like the fact that there are links to show me the new commits so I have a chance of vieweing them myself on GitHub.

26

It’s not something that should be built into the core. The CP directory will handle that. Core would then interface with the CP directory.

1 Like
27

How would the CP directory (and by extension my core install) be able to verify the integrity of the plugin files installed on my site, in the event a vulnerability is exploited, and my site gets hacked, if my local install can’t verify the integrity of the code by querying the source code repository?

And what if I install a plugin outside the CP plugin directory but using a vendor’s own GitLab server perhaps?

The code that CP is based on is a huge target for malware today. CP has an opportunity where WP doesn’t to implement a system that helps alleviate some of the shortcomings of the original design choices.

1 Like
30

Maybe i’m missing the point, but many times the repos are very different from the content of the zip release.

The repo can include PSDs sources, build scripts, tests, utility scripts that can get executed in a poorly configured server. How using git is supposed to deal with those situations?

2 Likes
32

Specifically to answer this, WordPress and security plugins handle this through file hashes. Core is easy. WP-CLI has it built in “wp core verify-checksums”.

Plugins/theme is a bit more complex. There’s no official source of checksums for each version of theme/plugin. So it’s not easy to implement. Shield Security plugin, which supports CP, does this by using their own hashing API service https://wphashes.com/

So maybe it’s something we can consider. Maybe directory could generate hashes and store them in a database or something, and CP could query them for verification. But it would be a larger effort.

2 Likes
33

With Github a hash is generated for releases automatically, so in theory we can check the zip hash to the release hashes we have in the directory, but then you get into weirdness with dev builds or manual updates (like we sometimes do to tweak plugins to match what we want) and stuff like that.

2 Likes
34

Discourse can do this because they run in docker, which means they have full control over the server environment. ClassicPress cannot.

In the ClassicPress ecosystem, this is a project that would require a full-time team of 5-10 people working on it for a year in order to have even a chance of being polished enough to ship, and even then I doubt it would succeed. Therefore it should be considered as currently out of scope for ClassicPress core.

If you want to try building it as a plugin, it could be a good business idea. But again, it is 10 or 100 times more difficult than you are imagining.

Using git to manage sites is a great idea, but if you want to do this then the quickest path is to learn to connect directly to your server via SSH and use the git executable. Servers and tech systems have multiple layers of functionality (to start: operating system, filesystem, user applications). It is simplest and most efficient to leave each task to the layer where it is most appropriately performed. If you want to make sure files are not modified, then the best way is to remove the permissions for ClassicPress to modify its own files using the capacity built in to the operating system.

The same goes for backups, by the way: this is best done by connecting directly to the server using an encrypted protocol like SFTP and fetching the files, and then using mysqldump to dump the database.

Taking the example of Discourse again, yes, they have solved both of these problems already. They were able to do this because (1) they require full control over their server environment, and (2) they have a full-time, paid team of multiple dedicated people working on these issues. ClassicPress does not meet either of these criteria.

5 Likes
35
36

I’ve used WP Pusher (https://wppusher.com/) for deployments where we had a lot of customizations that lived in child themes for a multisite. Because I had a system in place already I kinda did a thing where I mirrored my deployed plugins/themes, and used the “push-to-deploy” feature to keep several sites up-to-date from my, um, mono-distro-repos…

I don’t even know if that plugin works anymore, this was all prior to auto-updates in core, so it was a very different scene at the time. However, there is prior code to check and see how they handled checking hashes.

I thought of this because of a discussion point: git as a prerequisite. I used that plugin because at the time git was not something many folks offered. I’d say it is fairly standard for VPS distros, but I’m still interacting with a lot of shared hosting where it is unavailable.

(Quick aside: today I run a staging WP site where I update plugins one at a time, and after testing I go update on production sites I’m managing.)

And then… here’s a funny story: I don’t have git installed! I tried to clone a repo to fix a footer link the other day, since I needed to build the site to ensure the edits worked, rather than drive-by content edits through the web. Anyhow, no git! (I use Fossil, like I said, I’m slow ^_^.)

To me, that is a ringing +1 endorsement for composer! Rather than “git-php integration”, I think the broadest support effort would be documenting the composer install/upgrade path.

  • version control agnostic—use Git, Fossil, SVN, whatever Mercurial is… :crystal_ball:
  • very PHP—Composer is just some PHP itself, so if you can install ClassicPress, you can install composer!
  • next stop: ubiquity!—just as WP-CLI is all over the place (and relatively easy to install as well!), Composer is becoming available pre-installed on shared hosting (which could be bad if we think everyone in CP should use composer to upgrade, but it’s certainly handy for us devs/managers who have sites on shared hosting… :thinking:)
  • it’s already here—you can even use Composer to install dependencies from private repos, meaning entire projects can be managed with this one tool

Anyhow, thanks for the discussion, folks. It’s nice to here how folks are using technology to meet their requirements. :slight_smile:

37

As discussed, this petition is difficult to implement and better suited for a plugin. So it will be closed.

38

This topic was automatically closed after 3 days. New replies are no longer allowed.