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.
I meant more that code can be pushed to the repository without it being reviewed first, not that nobody is looking at it. If someone does push something bad are there systems in place to blacklist a plugin and remotely remove it from an install (and possibly contact the install owners)?
> 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.
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.