ellmann creative

If I may butt in and note something:

@dianosaure — please upgrade your PHP version, and if that’s impossible – please upgrade your hosting to something that uses a newer PHP version. PHP 5.3.* is veritably ancient, support for it ended 5 years and 7 months ago!

There’s a very public list of vulnerabilities your particular version (5.3.29) contains, four of which are high severity (low complexity of attack, no authentication required etc.).

Thanks for the update. ?? If it wasn’t already, I’m marking this as ‘resolved’.

I was also thinking you could probably use cURL (or any other remote access method that lets you perform a HEAD request) to see if the file exists and is accessible. It probably comes w/ its own set of possible issues (follow location? caching? would a redirect cause a 30x or a 200?), but it remains as an option should this issue resurface in the future.

I see this ticket is still open.

Was this issue resolved?

We also created a setting (…). Please enable that setting and run the test again (…).

Yeah, that works and reports success; that’s a final confirmation of source and scope of the issue.

—————————————-
As for testing w/ a local file… Well, there’s more to thumbnailing than just having the GD library, or Imagick, or write access. It’s a multi-step process, and it would make sense for the message to more accurately represent the stage that failed.

No, the biggest issue I really have with this situation is that handling “file-not-found” is completely and entirely your job as the programmer. ?? Bring to my attention things like broken PHP configurations, broken permissions and the like… but don’t cry to me about missing files that you yourself chose. ;] Find better files instead. ;P

I mean, I can’t theoretically fault you for not expecting a file-not-found there… but you know what they say… “A good programmer is someone who always looks both ways before crossing a one-way street.” ??

Though, in all honesty and joking aside, this does expose a possibly bigger issue I may have w/ WooCommerce (why would the file be missing if WP is supposedly tracking it?).

I actually went into /includes/WPThumb/wpthumb.php to see what file was causing the issue, and the file was /wp-content/uploads/2019/09/woocommerce-placeholder.png – which indeed does not exist at this time.

It would seem that your plugin got fooled into trying to use that file, for whatever reason. Perhaps you should include a dummy file with the plugin, so that it never fails an unintentional dependency check like this? ??

Also, that site is the only one I’m using WooCommerce on, so I can’t confirm whether this is a WooCommerce thing, or just a random bug that happened to hit me in particular. It does show an underlying issue in the test though, so I still think it should be fixed – in my opinion, any tests the plugin needs to run should be performed on known-good data.

I can however see the need to test your plugin’s ability to interact with WP as it does its job, so I can’t really fail you for using an uploaded image… But if such a failure is, as it turns out, possible… then maybe the code could try two-three images randomly before it reports a failure, or… it could possibly fake-upload an image, go through the motions, and then remove the fake once it’s done?

• This reply was modified 4 years, 8 months ago by ellmann creative. Reason: Added info about this being the only site with WooCommerce in use
• This reply was modified 4 years, 8 months ago by ellmann creative.
• This reply was modified 4 years, 8 months ago by ellmann creative. Reason: Included consideration for a possible fix

Actually, I think it might not be the upsell alert at all.

Hey FooGallery, your image generation test may be broken! ;D I get a persistent alert too, and it’s not about the upsell, but rather about a file being missing…

• This reply was modified 4 years, 8 months ago by ellmann creative.

I’m not saying you shouldn’t trust this update – I’m trying to say that it’s easily verifiable if you have basic PHP knowledge (and even if not, it’s fairly self-evident as to what’s going on w/ diff).

I’m just thinking that there’s a number of people who will come here and ultimately decide that it’s not worth their trouble… and I’m trying to be one of the voices saying “it’s legit” (while encouraging others to do it themselves, if they so choose).

Also, while the scope of the issue is fairly limited, the severity does seem high (judging alone by what’s been changed in the plugin), so I’d imagine people should want to upgrade to v4.0.2.

I would argue that this is a high-risk plugin, since it deals with security and therefore is trusted explicitly. As such, with this update being highly irregular, there’s a broad chain of trust that needs to be followed:

– that www.remarpro.com’s security hasn’t been compromised
– that your account hasn’t been compromised:
— that you don’t reuse passwords,
— that none of the sites you also use haven’t been compromised and used to reset your security or otherwise gain access to the account
— that your website hasn’t been compromised
– that the plugin wasn’t suspended for possible security violations (www.remarpro.com really isn’t transparent about these things…), or otherwise made to be suspended so that people would come to the Support threads seeking help (a perfect opportunity to serve someone a malicious “update”, wouldn’t you agree?)
– that the file wasn’t prepared with malicious payload as part of an ongoing attack

etc. etc. etc.

I don’t know you. It says “plugin contributor”, but there could be anyone hiding behind that handle right now. A short-lived attack could last only a few days and be so high-profile that the attacker might not care that this vector is then permanently patched up.

On the other hand, if I trusted all of the above explicitly when I installed the plugin from www.remarpro.com before – I can assume (without extensive code reviews) that the existing v4.0.1 I have on my disk is safe. Therefore, checking the code diff is a relatively simple procedure that only really costs me time (and, seeing as it only took under an hour w/ other activities, it’s not that high a cost to begin with).

No, I figured that – but this issue doesn’t just affect you, and I thought maybe someone else might benefit from me saying the above.

I’m not sure how much my word will mean to anyone, but… Since I don’t like to blindly download stuff (especially security-related stuff), I did a quick review of the changes made to the plugin (available on the link, file hashes – MD5: 664f37ae7ff5a5f872e9450317291e6e, sha256: c9b21c1d9f7093e7ae80b19d760fe89e4a78986a62a453551deab69984d3aea1) and they check out – the changes generally fall under removal of obsolete/insecure code, or shifting reliance to WP’s own role security.

If you happen to have an old copy (say, v4.0.1) of the plugin, nothing’s stopping you from performing a comparison yourself.

That’s not what I asked – I know how to check if GD2 or Imagick are present at the server. I want to know if there’s any way to check if WP is actually using one or the other easily?

Yes, it would seem that the issue that we’ve had between FileBird and FooGallery is now resolved.

Your gallery is working great, by the way! It’s exactly what we required, it fits our needs perfectly… I got to say an “I told you so!” ??

Thank you for your support!

We probably do (shared virtual – client’s choice), but is there some way to actually test this that WP Core actually uses Imagick or GD?

• This reply was modified 5 years, 2 months ago by ellmann creative.

Never mind – we found it in the gallery itself. We didn’t expect the button to be inside galleries instead of in settings.

Their website is quite online – though they haven’t updated it since July, it seems.