Otto42

"Cache-Control: private"

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.

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.

Plugins do not auto update by default. You have to specifically turn those on, and not via a switch, but via code editing.

Disclaimer: I wrote those guidelines.

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.

"Without review" is not quite true. Some of us get an email for every commit. Not kidding. Helps a lot for the scanning of things.

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: media, one step at a time. :)

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.

He's not muffled. He actually sounds like that. :)

Somehow I doubt that we'll decide to drop support for 65.5% of our users (roughly 26 million websites).

http://wordpress.org/about/stats/

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.

Wait, people actually use Yelp? Seriously?

I find that to be the most shocking statement in the article.

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.

So, when you have a problem with the system, then to find the bug you have to look in three or four places instead of one.

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.

The "serious performance issues" you speak of were fixed in core, about 11 days before your post.

See http://core.trac.wordpress.org/changeset/18541

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.

At the same time, virtually everybody I know who has tried Places has said the exact opposite.

To be fair, I have many friends who use Foursquare for its most obvious and intended purpose, which is to arrange spontaneous meetups without having to text all their friends where they are or to find out where everybody is going. I do it myself, I just pop open 4sq on the phone and see "oh, everybody is at Foo's Bar" and then go there. Easy. Facebook Places makes that simple action incredibly difficult and slow.

Places essentially fails as well because it broadens the userbase too much. My college friends whom I no longer live near couldn't care less what bar I'm at. My local friends who I'm friends with on 4sq do care. So there's a natural separation. I'm only 4sq friends with people I'm likely to see often. I'm Facebook friends with almost everybody I've ever known.

Location as meta is a good thing for Facebook. Location as check-in doesn't fit with Facebook's friend model.

Yeah, writing that importer was certainly annoying. Tumblr's formats are nutty and weird.

http://wordpress.org/extend/plugins/tumblr-importer/

I installed the Firefox 4 beta.

It's crap.

I've now removed it and will no longer be using Firefox.

Seriously, it is that bad, and will probably never get any better.

RIP Firefox. We hardly knew ye.

In the specific context of a GPL program, no, but there is case law backing up my argument. Micro Star v. Formgen for example, held that a Duke Nukem 3D map file (which contained no code or anything else from the game itself) was a derivative work because it referenced artwork and other materials from the game's files.

In the case of Excel macros, Microsoft have provided a public API within which to create those programs.

This is not the case for WordPress themes. Themes use the internal structures of WordPress to do their work, not the public APIs that WordPress provides.

The GPL has been upheld as a perfectly valid and enforceable license on many occasions. However, in all those cases, this happened via initial injunctions or the like, not in an actual final case itself. Basically, once the license was ruled valid by the judge, it becomes very clear that one side had no case and thus they settled to avoid a protracted suit.

The GPL is well-tested in that respect.

"If you make a theme that does not use any existing wordpress code, it wouldn't be considered a derivative work."

I personally would consider that to be impossible, however, you are basically correct.

In this specific case though, that does not apply. Thesis makes heavy use of WordPress code.

Anybody who buys it now can share it for free. You can get online, right now, and find a copy of thesis and download it without paying a dime.

People who are doing this sort of thing aren't going to be stopped by text in a license.

It does actually go deeper than that, but really that's beside the point. Function calls into the WordPress code is enough.

WordPress has a public API... several of them, in fact. A theme doesn't use those, it makes direct calls to internal WP code, and it uses WordPress internal data structures. This is enough to make it a derivative work.

From http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#Me... :

"Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL—if you can't, or won't, do that, you may not combine them.

What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."

Ultimately, it is a matter of interpretation, but all previous interpretation, including those made in courts of law, pretty much universally agree with Matt on this one. It's very difficult to consider a theme to be a "separate program" when it's deep-linking to internal functions and data structures and it also cannot run independently.

Read this: http://weblogtoolscollection.com/archives/2010/06/02/wordpre...

Then read this: http://ottopress.com/2010/wordpress-3-0-multisite-domain-map...

I use this exact method (and a subdirectory, not a subdomain install) to run multiple domains off on a WP 3.0 installation on cheap, shared, GoDaddy hosting. No apache config editing whatsoever.