Badly formed or empty plugin code in 4.8.8

gomedia · 2022-08-29 01:58:55

Have just upgraded a (locally hosted) site from 4.6.2 to 4.8.8 and I’m getting the above error when trying to upload plugins.

Yes, I’ve read this but it’s happening for all plugins, from any author.

Worked fine on a (locally hosted) site running 4.8.7, but then upgraded it to 4.8.8 and hit the error again.

Have tried reinstalling all the TXP files (using freshly downloaded versions).

Has something happened in 4.8.8 that might’ve caused this? Any thoughts on how to proceed?

Thanks.

gomedia · 2022-08-29 06:51:23

UPDATE

Switched PHP version from 5.6.21 to 7.3.29 and happy days!

Yes, I know I’m a bit old school but the System requirements for 4.8 still say PHP minimum 5.5.

phiw13 · 2022-08-29 07:34:30

v5.6.21 ? ouf… that is kinda old… I think those system requirement really should mention that those PHP 5.x versions kinda, eventually, work if you don’t ask much.

Glad to see you found a fix.

(don’t let Pete –gaekwad– see you… he might have nightmares ! again ! :-))

gomedia · 2022-08-29 22:47:37

phiw13 wrote #333852:

v5.6.21 ? ouf… that is kinda old…

Yep! But I was at least 1.21 inside the legal limits … perhaps a bit too close to the abyss?

etc · 2022-08-30 11:30:21

gomedia wrote #333850:

Has something happened in 4.8.8 that might’ve caused this? Any thoughts on how to proceed?

There seems to be not so much changes in txp_plugin.php itself between 4.8.7 and 4.8.8. Any clues on which function throws this error in debug mode?

gomedia · 2022-08-30 11:35:25

etc wrote #333854:

There seems to be not so much changes in txp_plugin.php itself between 4.8.7 and 4.8.8. Any clues on which function throws this error in debug mode?

Nope, just the red error message panel. I hacked txp_plugin.php and $plugin at line 536 appeared to be empty. Didn’t look any further.

etc · 2022-08-30 12:49:44

I think it’s php unserialize() function that causes this. In php 5 it takes only one argument, but two in php 7. The second one is security-related, so we have introduced it at some step, but now it breaks the php 5 compatibility. And if we merely remove it, php 7+ security will be at risk. Cool

etc · 2022-08-30 13:17:49

The guilty

Bloke · 2022-08-30 13:18:38

Shame we’re reliant on it for backwards compatibility because if there was any other method we could use (e.g. json_encode() with some binary flag) I’d much rather use that for bundling plugin code.

Is there a way we could investigate moving to a different method in the plugin template, make that the main method we try first when reading them in, and then just leave unserialize() as fallback? At least it’s off the critical path then.

Could we somehow introduce a plugin flag to indicate how it’s been prepared? Then we can use that to support different methods in future, based on the value supplied in the flag embedded in the compiled plugin itself or the bundled manifest if it’s a zip?

gaekwad · 2022-08-30 18:24:11

phiw13 wrote #333852:

v5.6.21 ?

[…]

(don’t let Pete –gaekwad– see you… he might have nightmares ! again ! :-))

I’m making that face again.

gaekwad · 2022-08-30 18:26:08

gomedia wrote #333851:

Yes, I know I’m a bit old school but the System requirements for 4.8 still say PHP minimum 5.5.

This seems like a good place to drop 1781 in for discussion. I am quietly hopeful that we can be brave and move on from some of the really old PHP releases in the next release branch.

etc · 2022-08-30 20:04:46

Unfortunately, as Stef says, the problem is unserialize() function itself. It’s a bit safer in 4.8.8 (at the price of php 7), but still not completely sure. A serialized malicious plugin could (try to) execute some bad action on unserialize, even before its code is previewed by the site admin.

I think this is one of these bw-incompatible changes we’ll have to introduce in some version (cf, maybe?). Meanwhile, a quick-n-dirty patch needs to be issued, thank you for the report.

Textpattern CMS

Textpattern CMS support forum

#1 2022-08-29 01:58:55