Once we were notified of the issue, I manually removed the bad code and shut down further updates. If you have this plugin, update to the latest version immediately.
The "Paypal" loophole is specifically because the first version of the guidelines had people constantly emailing us asking if this Paypal code snippet was okay. All the Paypal code snippet does (or used to do) is to include the relevant form data for "who to pay" in a base64 encoded mechanism instead of including the email address directly in the HTML code snippet. People didn't know what the code was, or if it was okay, and I wanted them to stop asking.
We still look for suspect code, and obfuscation that makes no sense is right out. We even reject minified JS, unless the minified JS is distributed from upstream code and can be verified to be unmodified from the original upstream source.
> are there systems in place to blacklist a plugin and remotely remove it from an install (and possibly contact the install owners)
We have automated scanning systems for suspicious code commits. If they occur, me and a few others get an email for manual review of the problem. Additionally, many others get every commit and set up their own scanning tools to see what's happening, as it happens.
When something-bad™ happens, then we can close a plugin (block it from being downloaded or found in searches), revert changes or otherwise manually adjust any aspect of the plugin, and if necessary, push updates for it to any WordPress installs that have it.
Realistically, bad actors are not generally a problem for the plugins system. I can count on one hand the number of times this has occurred to the point where we'd need to actually push code. The real problem we're fighting is accidental security issues. While WordPress core is quite secure, plugins have much less eyes on the problem, and a lot of plugin developers are relatively new coders. Things like simple SQL injections still pop up from time to time in plugins, and that's a big problem.
So, the security issues with with plugins repository is not really about some malicious person out there. Malicious people tend to be dumb spammers. They're easy to spot and protect against, because they're only after the low hanging fruit. What we mostly try to find are the things that good coding practices would protect against, because not everybody uses good coding practices. Those tend to be harder to scan for on an automatic basis.
We do monitor that sort of thing. Very closely. Oh, and I got that email too. They didn't really vet that email list very well, or they would have been smarter about it. :)
This is for backwards compatibility. If you checked it again after you login, you'd find that it is not an MD5 password anymore.
WordPress uses salted and hashed passwords with the phpass library, and has since version 2.5, released in 2008. Prior to that, it used MD5 passwords.
As part of the conversion process, it detects an MD5 password in the database on login, and then hashes the password to the newer salted mechanism, overwriting the MD5 version in the database.
@patio11: So, your attack basically amounts to "find RCE, then use RCE to gain control of whole network at once".
Okay, the problem with this argument is that it is technically valid on any network of any kind. If I invent magic exploit that lets me execute any code I choose, then I can gain control of entire network because I now can execute any code I choose on it. Sure. That much is obvious, but not specific to Bitcoin.
You originally put the price of "Subtle bug in the Satoshi client C code: $100,000" but without giving any meaningful reason behind this number. You know that throwing money at finding bugs doesn't actually find them, right? If the bug does not exist, then it cannot be exploited, no matter how much money is thrown at the problem.
Now, I'm not saying that there is no such bug, because I have no idea whether there is or not. However, when the existence of said bug translates directly into a money-stealing opportunity, in the most literal possible way I can imagine, then there is a rather large incentive amongst those concerned to make sure no such bug exists. I wouldn't be particularly surprised if that particular piece of code wasn't the most ridiculously oversecured thing you can imagine.
Now, obviously flaws can exist elsewhere, and often do. But you're pointing to something that is fundamental to the network and saying "what if it has a flaw", and that seems too obvious to actually be meaningful or insightful to me. Anything can have flaws. The useful question is not "what if there's a flaw?", but "does it have a flaw?".
Re: custom fields: This makes little to no sense to be in core, because custom fields are just that, "custom". There's no point in giving the end user the ability to make their own meta boxes hooked to custom post meta if there is no plugin or theme actually using that meta data. Creating a meta box is something that the theme/plugin should do, because it's actually going to use the data gained from that meta box.
In other words, the horse goes in front of the cart, not the other way 'round.
I wasn't actually responding directly to you, but I will.
Doesn't matter if you offer guest commenting by default. I close the browser tab the moment I see the non-standard comment box. I don't have any idea what hassles some arbitrary-comment system will have, so unless I really have something to say, then I'll just not bother.
I have a Disqus login, and sometimes I'll have something important enough to say that I'll go through the pain of using it. But it's not easy, nor simple to do. It adds extra burden on the user, and IMO reduces conversation on sites.
This is not unique to Disqus, the same problem exists for all third-party comment systems. The fact that the comment system is third-party is the fundamental problem that you'll need to overcome. When I see somebody else's branding on the comments, I'm out. Don't even stick around long enough to read them.
Agreed. If I see a third party commenting system, I typically just close the tab instead of leaving a comment. It's not worth the hassle to me to deal with whatever your commenting system requires.
Name/email/url. These three simple fields make it easy. Don't make me try to figure out how to talk back to you.
I'm sort of shocked that you're shocked. The rigid and inflexible architecture of systems like Rails and Django are the primary reasons for WP's success. There's a reason WP has more themes and plugins than these other systems, and that reason is ease-of-programming.
Every time I see some programmers advocating the use of highly rigid architectures or programming models, I'm forced to remind myself of Lisp. Lisp is the programming language. Lisp created most of the fundamental constructs you see in modern programming languages today. It's quite possible to do damn near anything in it, and it's arguably as close to the perfect mathematical construct of a computer language that can be made. It's a bit rigid and weird in it's syntax, but the list model is just great once you wrap your head around it.
On the other hand, the language that is clearly the most successful one ever is C, and it has often been argued to be the worst language ever. It has arcane syntax, it requires detailed knowledge of memory pointers and other oddities, and it's very much a lower level language. And yet it is clearly the most successful language ever. Why? Not because of its model or architecture (which are frankly terrible), but because of its flexibility. Programmers both inexperienced and experienced can use it to produce powerful systems. It covers the whole gamut of skill levels.
That's the problem with rigid architectures. Programmers tend to flock to them as they become better at their craft, because they provide organization and a system of management of the large scale code they're creating. But inexperienced programmers find the learning curve just a bit too steep.
You can't go from "Hello World" to creating a new WP theme in an MVC style. But you can go from basic HTML and PHP knowledge to creating a theme modification or a plugin. It may not be the technically best solution, but by god it'll get the job done for now. Speed of delivery matters, and if the choice is between doing-it-right and doing-it-right-now when you have a deadline and need to get paid, guess which path is going to get chosen?
Code has a limited life expectancy. It doesn't survive long in the wild, and this time is more and more frequently measured in years, not decades. So it doesn't make a lot of sense, in the long run, to spend extra time to build around a large framework when, damnit, we've got work to do. Every moment you spend learning yet-another-framework is a moment you didn't spend creating the next product and earning the next dollar.
Systems that are fast to learn and flexible enough to get the job done quickly always win over systems that are rigid and hard-to-learn.
Gotta say that I don't get it either. They've basically just added yet-another-HTML-templating system into the mix. Question not answered: "For the love of all that is holy, why?"
PHP is an HTML templating system. Tacking on yet another one strikes me as more than a little pointless.
I've gone by the name "Otto" for about half my life. It's a nickname I got in college. Many of my best friends didn't know my real name for years. It just never came up. My mom is the only person who uses my real name, and every now and then even she slips up. So when I go online, I tend to use "Otto" instead of "Samuel". Not trying to fool anybody, it's just the name I go by.
There's nothing special about a nickname, is there? Or do you not consider those to be pseudonyms?
Now, Google+ might have no problem with this, but I can't use just "Otto" there. It requires a first and last name, I believe. Also, I can't be "verified" under the name Otto. I currently am verified with my real name, via the old Knol trick from Google Profiles way back when. I kinda like the verification, and so use my real name there. But it's weird, as almost everybody both on and offline knows me by Otto, not by my real name. And if I change it, I'd lose the verified checkmark. Kinda annoying, that.
Google has to be respecting Cache-Control headers, right? Set your AMP pages to return that. Then they won't be allowed to cache them.