search

sandstormports / wordpress-sandstorm

WordPress Sandstorm package
Apache License 2.0
4 stars 3 forks source link

Should use a WP plugin to integrate with sandstorm rather than a fork #3

Open xet7 opened 6 years ago

xet7 commented 6 years ago

From @yuvipanda on June 21, 2015 12:25

WP is notorios for being insecure when left unupdated, and updating is hard when using forks :) Switch this to use a WP plugin than a fork.

Copied from original issue: dwrensha/wordpress-sandstorm#4

xet7 commented 6 years ago

From @ocdtrekkie on June 21, 2015 12:59

Likely a good suggestion, but a counter thought is: What happens if you're running WordPress in Sandstorm and you disable your Sandstorm integration plugin and can no longer authenticate?

xet7 commented 6 years ago

From @dwrensha on July 15, 2015 15:49

WP is notorious for being insecure when left unupdated

This is less of a problem on Sandstorm. The WordPress Sandstorm app only exposes static content to the outside world, disallows outgoing network requests, and is tightly sandboxed from the rest of your machine. There's a lot less to fear than with a standard WordPress install.

Switch this to use a WP plugin than a fork.

Much of the Sandstorm integration is already in a plugin. In fact, it's a must use plugin, so @ocdtrekkie's concern does not apply. I agree that it would be awesome if I didn't need to maintain a fork, but there are some obstacles:

  1. I don't know how we would handle automatic database initialization from a plugin. In principle, we could sidestep this issue by initializing the database statically.
  2. There are a few places (e.g. here and here) where the WordPress code really does need to be modified to place nicely with Sandstorm.
xet7 commented 6 years ago

From @meitar on April 25, 2016 21:21

There are a few places (e.g. here and here) where the WordPress code really does need to be modified to place nicely with Sandstorm.

Some of these issues could be resolved by getting a little fancy with PHP's output buffering. You could ob_start() during your plugin's init and then during a WP shutdown hook you could ob_get_contents(), replace the target attributes to your liking with WP's links_add_target() function, and then print your modified output.

I know that won't take care of all the patches you need to make but maybe it would be easier to maintain the fork with fewer patches?

Just a thought.

xet7 commented 6 years ago

From @dwrensha on April 25, 2016 23:35

Wow, output buffering looks like it could really come in handy sometimes. I'm not sure that it is worth the trouble in this particular case, but it definitely seems useful to know about.

searoso commented 5 years ago

Is it really an issue in Sandstorm environment? Static pages, enforced user management. Doesn't look so scary.

Is there a way to collect/disclose any estimations on the number for percentage of SS WP that was ever infected? And it's interesting how relevant are https://nvd.nist.gov/view/vuln/search-results?query=wordpress&search_type=all&cves=on to Sandstorm case.

tian2992 commented 5 years ago

I see it as it probably should be a diff that is ran within the package build process, this way we have repeatability and the chance to update with as few delay as possible.

JamborJan commented 5 years ago

Do you have the chance to code an example? Any help or suggestion is welcome. Thanks for taking to contribute!