191–200 of 210 posts
Link to the delta from the latest code revision where they replaced “ACF” with “SCF”. 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.
Earlier quoted context omitted.
Nothing has broken. Perhaps WP Engine should have consider that before suing us.
I don't think punishing people for suing you typically plays well in court. Especially not if you, you know, publicly announce that's what you're doing.
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.
This 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.
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.
Earlier quoted context omitted.
The fucked thing is that per the article, they're not even dedicating any resources to maintain it going forward, they've just made this one fix and are throwing it to other people to maintain if they want: > 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.
We have taken on stewardship of this code going forward, and will dedicate engineers to it. Probably more than Silver Lake does.
Earlier quoted context omitted.
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 permalin…
Not good.
This 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.
Earlier quoted context omitted.
Have you read the GPL?
Have you read https://trademarks.justia.com/983/21/advanced-custom-9832116... and https://trademarks.justia.com/983/21/acf-98321135.html ?
So far even USPTO attorneys think it's a generic mark not worthy of being registered: https://tsdr.uspto.gov/documentviewer?caseId=sn98321164&docI...
Earlier 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…
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.
Earlier quoted context omitted.
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…
If the codebase was built on the assumption that user callbacks will execute in a context where POST data is sanitized (which is evidenced by the code that was already there), then failing to sanitize $_REQUEST in addition to $_POST is certainly a security issue. 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 tha…
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.