The URL though says "advanced-custom-fields"; Matt...I can't find the words to comment; I just shake my head -_-
replies(1):
What a terrible look
They also modified it by ripping out the pro features, so if people update their ACF Plugin and they had pro features enabled, it'll just break their install
https://plugins.trac.wordpress.org/changeset/3167679/advance...
https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph...
Not a lawyer, but since WPE sells ACF services, can WP redirect users away? That is directly impacting a competitor’s bottom line.
This --- to me --- smacks of complete bullshit.
Anything to prop up their position and throw the company they are attacking under the bus. What a jerk.
1) WordPress clearly lacks functionality like ACF that belongs in core
2) Many developers clearly like ACF
3) Many do not (it's messy in the DB, if you ask me)
4) Core functionality that was if not API-compatible, at least API-familiar with ACF would be welcomed by many
5) Creating a new plugin that did this, that was transitioned into core (like other functionality has been), would be a good plan
6) Commandeering the slug for a decade-old commercial plugin like this, to replace it with a fork, is so obviously fucking bad form that it's still hard to believe it is happening even given all the other whatthefuckery that has been happening.
ETA: 7) "Secure Custom Fields"? Really? The difference is what?
What the fuck, Matt?
ETA: personally I understand many of the frustrations with WP Engine's positioning. I have experienced exactly the trademark confusion issues that the lawsuit has been about, where clients have assumed WP Engine is WordPress itself. I don't use them after some iffy customer service and technical issues early on. But this is absurd behaviour.
This is a rare and unusual situation brought on by WP Engine’s legal attacks, we do not anticipate this happening for other plugins.
What am I missing?
> 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 are going to set off on your own, and not inhabit the dead flesh of the project you just killed.
Matt Mullenweg is the biggest child I have ever seen in operation.
Is there a repo of this website?
It would be good to have for preservation purposes.
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-inflicted destruction
*Update* Oh, it's worse than that. He just renamed the ACF to SCF and claimed all the installations and reviews from ACF. I still can't believe this happened. This can't be legal!
It's fixing a security issue WP Engine cannot fix because they are banned from wordpress.org.
Though, Automattic posted publicly that there was a vulnerability shortly after filing the CVE, while simultaneously blocking WPEngine from being able to push a fix to it because they'd cut off access to wp.org
Wordpress sites quite often seen to be a hodge-podge of plugins, each with their own UI and conventions, and (as a host) I'm never an expert in anye one of them. Has one of the site designers used a plugin that has offended Matt? Or that might offend him in the near future? How do I even audit for that?
I don't need much of a push to move my position on this. Before: "eh, use Wordpress if it's cheaper" Now: "please don't, that decision will probably cost me".
> Going forward, Secure Custom Fields is now a non-commercial plugin, and if any developers want to get involved in maintaining and improving it, please get in touch.
ETA: Matt says[3] it’s a different vulnerability. Anybody willing to break out the almighty diff?
[1] Discussed at the time: https://news.ycombinator.com/item?id=41752289
[2] https://www.advancedcustomfields.com/blog/acf-6-3-8-security...
I honestly don't see why anyone would treat this as a security issue. Everything involved is PHP code that can do whatever it wants, not in any kind of sandbox.
Edit: And even if it were this update doesn't fix the problem. POST variables can still be accessed:
filter_input(INPUT_POST, 'name');
The linked post also might not reflect the current policies. This update was a security update and was done due to the unique circumstances around the original publisher.
I'm really turned down from the whole ecosystem by this total shitshow. Seems like everything could be pulled from under running sites if some clown decides he doesn't like it anymore.
At this point I just hope that WP Engine wins whatever lawsuit happens and Matt Mullenweg (and everybody who was involved besides him) has to pack his things and leave everything WP-related forever.
Was that not true?
[1] https://x.com/wp_acf/status/1843376378210857441
https://github.com/sc0ttkclark/wordpress-fields-api
I'm not entirely sure what it is but it has over 350 stars and quite a few forks so it's probably important.
Isn't it here?
https://github.com/AdvancedCustomFields/acf
If you mean the licence, it's in readme.txt:
https://github.com/AdvancedCustomFields/acf/blob/master/read...
To that end, we reserve the following rights: ... to make changes to a plugin, without developer consent, in the interest of public safety.
GPL code, trademarked branding. If you want to fork then you have to actually fork.
Oh the irony.
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.
They did:
Advanced Custom Fields — https://tsdr.uspto.gov/#caseNumber=98321164&caseSearchType=U...
ACF — https://tsdr.uspto.gov/#caseNumber=98321135&caseSearchType=U...
While technically they own the platform and can do whatever they want, there is clearly ill intent here and it'll be used against them.
Lines have been crossed when stealing other people's code, what happened in the case of ACF to SCF, IMHO.
I'm not sure where values come into it. I'd be ashamed to work there.
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 renames it.
It's not "important", it's just deeply weird, because it tracks.
Also the guy is in a hot tub with all of his friends and employees
Let's look at newer documentation:
https://developer.wordpress.org/plugins/wordpress-org/detail...
> The use of trademarks or other projects as the sole or initial term of a plugin slug is prohibited unless proof of legal ownership/representation can be confirmed
The plugin is at https://wordpress.org/plugins/advanced-custom-fields and advanced custom fields filed for trademark last December https://trademarks.justia.com/983/21/advanced-custom-9832116...
Also
https://developer.wordpress.org/plugins/wordpress-org/plugin...
> We also don’t accept 100% copies of other people’s work
There's a clause which looks applicable https://developer.wordpress.org/plugins/wordpress-org/plugin...
> What happens to a plugin if the plugin owner gets blocked?
however the page says "Last Updated: 12 October 2024" and https://github.com/WordPress/developer-plugins-handbook/blob... (permalink at the time of writing this) doesn't have this section. So it really looks someone manually edited the page on wordpress.org without editing the source. Now, who has such permissions and has the motive to do this?
Pot... Kettle... Something, something.
A lot of the comments seem to call out Matt (right or wrong). But that’s the easy thing to do.
No one dares address the systemic issue of for profit corporations exploitatively (ab)using open source software.
There is a social contract that people should contribute back, and while it’s largely unenforceable, as it should be, when it’s happening on a systemic level something has to be done. And we are all complicit if we don’t at least say that much and spare some good will towards the guy actively in that fight at least superficially
*Following is a response to some replies on the other thread, that clarifies my points *
Matt being a poor steward of gpl is by definition not a systemic issue … unless ur claim is that many people in positions like him do what he does which is in turn caused by invariant factors?
The systemic issue is companies the world over not giving their fair share back in terms of contributing to foss.
I might agree with most of your points, I’m just trying to get people to realize there’s the local issue of Matt/wp and then there’s this global issue of companies building businesses off foss and not giving back.
If you "fork" the assets, you're not covered by GPL.
Obviously it's nonsense to discriminate between the free version of a freemium plugin and a commercial plugin and this is simply a stupid way to lash out.
I think we're pretty far removed from the original issue of WP Engine and WordPress and people are just trying to deal with the fallout from Matt's nuke-the-entire-ecosystem approach he's elected to take.
It makes Drupal 8/Backdrop seem like a pleasant and wonderful experience, in comparison.
We had hard forks of very popular systems before, e.g. xfree86 turned into x.org, LibreOffice vs OpenOffice.org, Hudson to Jenkins and others and basically everyone switched (nearly) overnight.
Fork will likely have a much better direction structure to avoid precisely this problem, at least it seems to be the pattern.
In short, I know I considered Backdrop futile but I don't think there was any significant controversy or is my memory failing me? http://www.drupal4hu.com/node/380 here's my post from the time.
Truth to be told there was significantly more controversy between me and the rest of the Drupal community than Backdrop and Drupal. You can not imagine how much I regret that.
It's also productive. If there's enough of an uproar, then the board will remove him. They're pretty much the only people who can stop him.
> There is a social contract that people should contribute back, and while it’s largely unenforceable, as it should be, when it’s happening on a systemic level something has to be done. And we are all complicit if we don’t at least say that much and spare some good will towards the guy actively in that fight at least superficially
You don't speak for me. Contributions to my OSS projects are appreciated, but all I ask is that users comply with the license terms.
If you feel that contributions are an unwritten obligation, he's made them much harder to ask for. Everyone else who asks for them in the future will be tarred with the same brush.
Matt is burning down the WordPress ecosystem because his shakedown attempt failed. He's prevented at least 2.5 million users from receiving security updates. He's earned my contempt, not my goodwill.
> I might agree with most of your points, I’m just trying to get people to realize there’s the local issue of Matt/wp and then there’s this global issue of companies building businesses off foss and not giving back.
Drew said it best. (https://drewdevault.com/2021/01/20/FOSS-is-to-surrender-your...) If you want to require contributions, pick an appropriate license.
Childish.
[1] https://duerrenberger.dev/blog/2024/10/08/timeline-of-the-wo...
1. https://wordpress.org/support/topic/future-updates-for-acf-a...
2. https://github.com/wordpress/wporg-plugin-guidelines/blob/tr...
If you used ACF pro then the plug-in is downloaded from ACF website.
But.
The obvious next move is to put code in the core that would degrade ACF pro.
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 back then, especially as Wordpress and Drupal were often considered in the same meetings when building small local sites for nonprofits, small businesses, etc.
Nowadays it seems Drupal isn't part of the conversation unless there's a C-suite at the place building the website, it's moved upmarket quite a bit.
Similarly, this is all to resolve the personal grudge of an exceedingly rich dude who wants even more money.
That was a great article from drupal. It’s a great idea and really goes along way to help, but we still need more.
This only addresses foss projects that are hosted as an offering. It wouldn’t address how for example the pgp guy basically went broke or just the general amount of pressure maintainers of “critical” foss packages are under and are spread so thin, that it’s always a triage fire and there’s never any room to “level up” with rewrites or full code base audits. And a lot of it comes at a huge personal cost but it just so happens the people often times in those shoes end up being super noble.
Maybe this is a cynical take but year after year it really does seem the software we rely on for modern life is just a house of cards where most cards are solo devs or a handful each doing the task of atlas cus the worlds corporations just don’t give back!
My words will ring true in 10-20 years when most of these people kick the bucket or retire and all we have left will be google’s next android| fuchsia and windows server.
- Matt
- the people who didn't quit Automattic last week
- _maybe_ the WP core developers who don't work at Automattic, so long as they keep their criticisms to themselves
Then, you added a few irrelevant changes that to the inexperienced eye look like security fixes https://plugins.trac.wordpress.org/changeset?old_path=%2Fadv...
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
Unless you show proof of a security fix - which you could have pushed to users WITHOUT renaming the plugin, WITHOUT removing original, non-security related code, and WITHOUT breaking compatibility with the PRO features - you have LIED and STOLEN code in the name of WP.ORG
This will hopefully be recognized by WP Engine and if god wills, remove you from the equation once and for all legally speaking.
For WordPress _users_, as in the people who log into the WordPress dashboard to run their website, 'stuck in the past' is often an advantage and not a bad thing. You'll be able to find blog posts and tutorials and youtube showing you how to use in, unlike the "new shiny" where there's no easily found example or support for.
I wouldn't call it high quality though. 200k LOC even for the free version (I use pro), no OOP, global variables, bugs get no attention unless they're major. It was amazing when it first came out, but it has fallen behind even compared to core + other plugins (and the WP average is a very low bar).
It clearly belongs in core, just like 90% of Yoast's (or AIOSEO's, Rank Math') functionality, Redirection and permalinks, and they should have focused on getting that done instead of gutenberg. But also clearly this isn't the way to bring it into core.
In your perspective - what does it look like? What could be done to go the opposite way and keep going?
Also, I'm surprised to see people only siding with WP Engine here. Usually the discussions here are much more balanced.. What do you think could be the reason for it?
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.
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?
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.
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.
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.
There is no dispute over the facts here if Matt is just going to announce his intents.
I cannot imagine his rage when not only does WPE not have to pay him, but now he’s paying them.
People want him removed from Wordpress leadership to protect Wordpress. The harm to him is really orthogonal to the greater goal of not destroying the software that runs 40% of the internet or whatever, triggering man-centuries of pointless labor to replace it across all those installs.
Given the options of letting Matt tear the ecosystem apart or letting the ecosystem tear Matt apart (figuratively, not literally), the ecosystem should win. It sucks for Matt, but wasting cumulative lifetimes of human effort to migrate all these installs is stupid and not worth saving one man’s ego over.
So far even USPTO attorneys think it's a generic mark not worthy of being registered: https://tsdr.uspto.gov/documentviewer?caseId=sn98321164&docI...
Of course, relying on such simplistic measures is still brittle and inelegant, but that's another matter. Reworking it would likely be quite invasive to that codebase and far beyond the scope of a security patch.
(also, frankly, the entire WordPress ecosystem isn't particularly known for its high quality codebase... this kind of "fix" is exactly what you'd expect there even without all that drama around)
> Security issues can be fixed WITHOUT renaming the plugin or removing links and text even if the original author has no access anymore
Not sure who you're arguing with there, but certainly not with me.
You have plenty of shitty behavior to call out there, so not sure why you decided to announce that there's no security issue being handled at all instead. It only makes your point weaker for no good reason.
How on earth does emptying POST or REQUEST solve anything at all in regards? How on earth does, no matter what crap ACF added BEFORE the takeover, this "Fix" justify a hostile takeover? If or not there is a security issue with this code (which there IS, but not with POST or REQUEST data) is not even the matter anymore - it was and is posed and defended as a "urgent action to fix a security issue in a plugin the author has no access to"
And I repeat - there has not been any security fix!!
Read my root comment: > because the only relevant changes are actually neither introducing fixes, nor ever changing the plugin core code in a way that fixes security issues.
And I stand by that. Anyone reading this code can see it.
I haven't watched the video, but if it's a small amount of blood it's perfectly possible he just didn't notice.
That said, you clearly seem to be confused about the nature of the issue being fixed there. It's clear from the existing code that the contract between this function and the callback getting executed is that the callback is expected to execute in a kind of a sanitized environment with restricted execution abilities.
You can argue that it's a really weak sandbox and that the whole design is smelly, and I'll agree with you. However, that's how this code was designed and that's what users are running on their servers, and that's how they expect it to behave. It prevents the callback from calling functions with `wp_` prefix and it disallows it from reading or making changes to user's POST data.
Now, if you find a way to circumvent those restrictions, it's an obvious security issue. Someone may have deployed some code that relied on that contract, and now that contract is known to be invalid (it always had been, but it wasn't known before). Therefore, stopping that from happening is a security fix.
It may be a poor fix - and in fact, this one is, as it's incomplete. But it's a fix. The upstream project recognized that and applied a similar, but a bit more thorough approach in its repo:
https://github.com/AdvancedCustomFields/acf/commit/a60034f8a...
It does exactly what the change we're discussing does, plus a bit more.
You still wouldn't convince me that it's a bulletproof sandbox and I already have some other ideas in my head on how it could potentially be circumvented after reading that code (though my PHP is so rusty I may very well be wrong), but the change in question is clearly a security fix, recognized and applied by both Automattic and WP Engine and I really can't understand why you're so keen on implying otherwise. As I already said, it only made your other (good) points seem weaker.
call_user_func was still called. Clearly, the idea behind is is not "some kind of sanitized env" since the start. The idea was "the user can throw in a callback and it will be executed". Then someone said "but that is unsafe" (And it is!) But the unsafely thing here is not "You have access to POST data or wp_ functions". That is the default in ANY code attached to WP anyway, and while being part of the danger here, the real danger is that an arbitrary POST EDITOR can throw in a callback and it executes that.
Which is why, yes, somehow, clearing posted data and excluding already existing methods like wp_ stuff is sort of a "fix" for that, since before the Post Editor did not even need to write the callbacks code: he could just have called a eventually bad (in context) registered method in core. So the "fix" does somehow mitigate, but not fix the issue.
I can see upstream builds on that idea even more. However the code still uses user callbacks, and those user callbacks can still be unsafe. You just need to throw in a callback that does something malicious, which does not even be an obvious malicious code. It could be a callback registered elsewhere, where the else context makes sense and is not flagged, but in conjunction with this ACF feature, would be malicious.
It should be clear that the security issue here is not what you can access during that callback - the security issue is that the callbacks are not whitelisted, and/or allowed at all (which can be considered a problem too, but would break potency of the features of course if removed)
Not putting my hands in fire for this, but I believe there is reason I Could not find a CVE yet for this alleged security issue, only a reserved one. I suspect that is, because the issue is still there, and publishing it, would immediately render it more dangerous. I again would love to learn that I am wrong here.
I do stand by my original post that said: > because the only relevant changes are actually neither introducing fixes, nor ever changing the plugin core code in a way that fixes security issues.
This stands true: the security issue was not fixed. If we start to call incomplete fixes a fix, then we can as well call anything anywhere a fix. Heck, I moved around some lines and cleared some of the data. It's fixed! That would never hold true. In all and every case, plugin review team would immediately review the FIX before you can even say "but", and they would immediately throw it back at you, asking for an _actual_ fix. Especially with call_user_func. This has not happened here at all, which just adds to the fun of the day.
I feel the discussion should evolve around this, and The Guys who yelled "Security" should come forward and explain to the public what they actually fixed, if they truly believe this fixes the issue, if they truly believe that ACF (sorry, SCF) is now _safe_, or not.
My point stands that it (the core issue) has not been fixed.
Sorry if it got a long post.
The real danger is that an arbitrary post editor can throw in a callback and it gets executed unsanitized. Having a proper sandbox would be a perfectly valid solution - in the end, that's the whole modus operandi of the web browser you're using to write these comments. And yes, I also have doubts whether the implemented measures are nearly enough to actually sanitize the input; I'm also not sure whether you can sandbox that feature properly without making it effectively useless - and while neither of those justify Automattic's behavior, it's a different accusation.
I think we might agree - and my original wording was tainted by emotions.
- indeed, there was changes in code that can be sold as “attempted security fix” - indeed, as I think we both agree, the main security issue still needs attention to this very day