Pathetic. Matt banned one of the most popular WordPress plugins. Then, he forked the code and hosted it on WP.org, which is against the Terms of Service. He also hosted it in the plugin directory on the same path as ACF, stealing its SEO traffic. Wow! Matt's state of mind is clearly not good. If I were an investor in WordPress, I would start thinking about cutting my losses. WordPress will not recover from this self-…
Have you read the GPL?
Secure Custom Fields by WordPress.org
181–190 of 210 posts
Re: Secure Custom Fields by WordPress.org
#182This is a human being, making a mistake, only to be bullied by literally the whole internet? Never have I ever witnessed a lynch with any positive consequence whats so ever in my entire life. Empathy all the way. We all make mistakes. Stay kind and positive.
Actively running a harassment campaign against a competitor is not "making a mistake".
Re: Secure Custom Fields by WordPress.org
#183Earlier quoted context omitted.
I'm glad but slightly surprised neither Crell nor me counts as worst drama for you. Good? I guess.
Well instances were both painful but in my mind mostly affected a few core groups of devs, and a lot of the community was oblivious to anything going on. The Drupal 8 migration and subsequent forking of D7 into Backdrop caused a lot more consternation with smaller agencies especially. I mostly did Drupal stuff with local and regional camps at the time, I was hired at Acquia slightly after, so I remember a lot of pain…
It sure did. Dries cashed out thanks said upwards movement and then he realized this move destroyed the contributor pipeline (make a personal/charity/etc small website-tinker Drupal-contribute to Drupal) and also market share so he now tries to move it back down with Starshot. I wish him the best.
Re: Secure Custom Fields by WordPress.org
#184Earlier quoted context omitted.
This release fixes a separate security vulnerability from the original update.
Unfortunately you have no proof of that, because the only relevant changes are actually neither introducing fixes, nor ever changing the plugin core code in a way that fixes security issues. The only thing done is removing a LOT of references, links, and instructions that would remind of WP Engine, as well as all compatibility with the POR features. Then, you added a few irrelevant changes that to the inexperienced e…
> However, these are no fixes. You just introduce a new variable, that you never use, and re-assign the same contents of that new variable back to the $_REQUEST
While this whole takeover thing is completely ridiculous, it's you who displays an "inexperienced eye" here. What do you think the $original_post variable (which was already there) is doing, huh?
Re: Secure Custom Fields by WordPress.org
#185Earlier quoted context omitted.
There are a lot of other employers that won't make you lie for them.
If you point to any lies told by me, I would love to correct them. No one has told me to come here and defend anyone. I work at a part of Automattic that is isolated from anything WordPress — I don’t have to be here. I am defending values I believe in. I am trying to make sure correct information is out there. You are free to not believe that of course.
[dead]
Re: Secure Custom Fields by WordPress.org
#186Re: Secure Custom Fields by WordPress.org
#187> This update is as minimal as possible to fix the security issue. > This is a rare and unusual situation brought on by WP Engine’s legal attacks, we do not anticipate this happening for other plugins. So.. is this fixing a security issue.. or is this because of WP Engine? > and are forking Advanced Custom Fields (ACF) into a new plugin And stealing their place in the plugin store. A fork generally implies that you a…
> So.. is this fixing a security issue.. or is this because of WP Engine? AFAIK, here's the timeline. 1. Automattic announced that there was a security issue in ACF. 2. WP Engine fixes it immediately. 3. Automattic bans the WP Engine developers from Wordpress.org, so they can't deploy the fix. This places millions of users at risk, but that's how they roll. 4. Automattic forks ACF, removes the commercial upgrade, and…
Not a fork. They just took over the account/listing, which preserves 1200 reviews, etc. As fascinating as it is deplorable.
Re: Secure Custom Fields by WordPress.org
#188Earlier quoted context omitted.
Unfortunately you have no proof of that, because the only relevant changes are actually neither introducing fixes, nor ever changing the plugin core code in a way that fixes security issues. The only thing done is removing a LOT of references, links, and instructions that would remind of WP Engine, as well as all compatibility with the POR features. Then, you added a few irrelevant changes that to the inexperienced e…
> However, these are no fixes. You just introduce a new variable, that you never use, and re-assign the same contents of that new variable back to the $_REQUEST While this whole takeover thing is completely ridiculous, it's you who displays an "inexperienced eye" here. What do you think the $original_post variable (which was already there) is doing, huh?
The same. Nothing. The “security” issue here would be that the user callback can access post and request data. Tell me one place in the entire wp code base where that is NOT possible?
Security issues can be fixed WITHOUT renaming the plugin or removing links and text even if the original author has no access anymore
And that “fix” is ridiculous. If anything it breaks code of users who were actually adding callbacks using that data. It’s the nature of php that you can access those details - it’s up to the caller to know what to do with it. If anything, the usage of user callback is an issue here.
And in any thinkable case this ain’t a security fix that was done. A security fix would include that and only that change.
Re: Secure Custom Fields by WordPress.org
#189Earlier quoted context omitted.
> However, these are no fixes. You just introduce a new variable, that you never use, and re-assign the same contents of that new variable back to the $_REQUEST While this whole takeover thing is completely ridiculous, it's you who displays an "inexperienced eye" here. What do you think the $original_post variable (which was already there) is doing, huh?
The same. Nothing. The “security” issue here would be that the user callback can access post and request data. Tell me one place in the entire wp code base where that is NOT possible? Security issues can be fixed WITHOUT renaming the plugin or removing links and text even if the original author has no access anymore And that “fix” is ridiculous. If anything it breaks code of users who were actually adding callbacks u…
For some context how you MIGHT actually “fix” the true security concern in this code:
$allowed_callbacks = ['some_function', 'another_function']; // Example of allowed functions
if ( in_array($original_cb, $allowed_callbacks, true) && is_callable($original_cb) ) {
$return = call_user_func($original_cb, $post);
} else {
// Log or handle invalid callbacks safely
$return = false;
}
Tampering with global variables or else is NOT a fix, and this one in particular is like pointing out a crumb on the child’s mouth and grounding it for not brushing its teeth.
You could apply a filter to allow filtering the allowed callbacks, if you really want to allow more than the hardcoded whitelist.
In the end it still boils down to “do not use user callbacks” as the better security fix, which again shows how “they” didn’t fix a thing here. This is a blatant excuse for legal CYA.
Re: Secure Custom Fields by WordPress.org
#190Earlier quoted context omitted.
Oh nice. Then WordPress shouldn’t be able to take over without renaming, right?
they renamed to "secure custom fields"
They kept the permalink afaik, which is probably still likely to cause confusion in the marketplace and may still be a trademark issue.
Without knowing this drama, if I found and clicked an ACF link on a 2 year old Reddit post and ended up at Secure Custom Fields, I’m not sure I’d know it wasn’t by the ACF folks. Just their branding for the v2 or whatever. I think customers have a reasonable expectation that permalinks won’t take them to unrelated products.