WordPress 2.6 – Causing waves on Mars: The XMLRPC controversy
June 26, 2008
WordPress 2.6 has been been trouble. There’s been confusion about whether it would be out in July or August. There was one date in the road map, and one in Trac. On Sunday night, Charles Stricklin and I recorded episode 43 of The WordPress Podcast and I stuck with the August date that was in the Trac tool used for development.
Then the next day Ryan Boren sent this reply to the WP Testers mailing list the next day:
On Mon, Jun 23, 2008 at 1:01 PM, Kirk M wrote:
> Do my eyes deceive me or am I seeing a due date of July 7th for the release
> of 2.6 with a fall back for July 14? Any reason for the releasing a month
> early? I’ve barely setup my test sites figuring I had a month to go ye;).[Ryan Boren Replied:]
There was some confusion because the roadmap had July and trac had
August. Given that all of the features went into 2.6 early and that
its been running this whole time on wordpress.com and lots of our
personal blogs, a shorter beta seems doable. I think we can launch
the beta cycle now, pound on it until the 7th and decide if it’s
ready. If not, pound it another week and decide of it’s ready. I
merge 2.6 to wordpress.com almost daily and get tons of feedback in an
instant. I’m pretty confident in being able to finish off 2.6 in a
few weeks. We won’t be adding any more features to 2.6 so there’s no
need to linger for an extra month. Also, a July 2.6 release allows us
to consider an early September 2.7 release that focuses on pulling in
some of the GSoC work. That work would be too much to try to push
into an early August 2.6 release.
Ah, well you win some you lose some. At least I wasn’t the only one who thought it would be August.
Since then a much more controversial debate has arisen. Westi made the announcement that WordPress 2.6 would have the XMLRPC feature turned off. XMLRPC is the technology that allows programs like Windows Live Writer, MarsEdit, ecto and other external blog editors use to communicate with your WordPress blog. Here is what Westi had to say about it in his announcement:
WordPress 2.6 will be more secure out-of-the box including better support for running the admin over SSL and changes to disable the remote publishing protocols by default.
We have choosen to disable Atom Publishing Protocol and the variety of XML-RPC protocols by default as they expose a potential to be a security risk. So from WordPress 2.6 onwards you will need to go into the Settings->Write page and enable them individually if you want to use them.
Mac software developer and MarsEdit creator Daniel Jalkut believes this to be a fundamentally wrong choice. He’s said so on the wp-hackers list and on his website:
WordPress’s decision to shut off remote access by default is analogous to a bank offering unrestricted drive-through access to its cash machines, while requiring pedestrians to ring a bell and wait for a security guard to open the door to the machines.
Also worth considering: if a service is disabled by default for security considerations, what message does that send to people who choose to, or who are encouraged to turn the service back on? It sets up a perception of insecurity which may not even be warranted. If the remote publishing interfaces are insecure, they should be fixed, not merely disabled!
I think that’s somewhat misleading. It makes people think that the switch has to be set over and over again. It is much more like, when you open a savings account, checking either the box that says you want an ATM Debit card and/or the box saying you want to access the account through the online site. Eliminating either of those options would make your money more secure.
I agree that there is an issue with people upgrading and finding that MarsEdit, Livewriter or whatever doesn’t work. That is easily solved by keeping the XML interface off by default on new blogs, but not changing the behaviour for upgrades.
But why not just “fix” the security issues? Well the truth of the matter is that you can no more "fix" all security risk in xmlrpc than you can "fix" it in any software program. It is a moving target. New methods are thought of and software improvements introduce new avenues never thought of, even if there is a layer between the final interface and the database. So even if WordPress was completely clean in 2.6, how can you prove that it is secure in 2.8 or 3.0.
Is xmlRPC secure in WordPress 3.0? I don’t know it doesn’t exist yet. But I do know if it is disabled for new blogs, that the new WordPress 3.0 blogs won’t face an XMLRPC security risk.
Article Series - WordPress 2.6
- WordPress 2.6 – Causing waves on Mars: The XMLRPC controversy
Comments
6 Responses to “WordPress 2.6 – Causing waves on Mars: The XMLRPC controversy”
Got something to say?
The problem with disabling a feature that has always been enabled is that you’re going to inadvertently turn off a lot of people who may have managed apps and integrations. I know several companies that support third-party WordPress installations.
The better approach is to simply ASK the person in the upgrade process! A simple screen that says, “XML-RPC is currently enabled, would you like to disable it? [More Info Link Here].
It’s simply a bad process to upgrade someone and disable features that were previously enabled.
AFAIK, it doesn’t ask you to enable it for an upgrade (at least, I don’t remember it asking me). But for a new install, it does ask you if you would like to enable.
I think the best approach would be to also ask during an upgrade (after checking admin auth credentials).
The update process has never been interactive I don’t think I would change this. Actually I don’t think this needs to be as comlicated as ppl are maiking it. Old blogs can get grandfathered in having it turned on during the upgrade process. New blogs have it turned on by default. Don’t bother putting in a checkbox or anything in the upgrade process. When CrazyHorse comes out an announcement can be added to the inbox that says “You have this on. If you don’t use it, turn it off.” The blogger reads it, dismisses it and takes action if they want to. If the inbox implementation allows, it can have an “Address this issue” link that connect to the page with the check box on it.
1. New blogs are safe
2. No one loses features
3. Bloggers are made aware of how to increase the security of their blog.
All concerns have been addressed. Yes?
I’m fairly sure that it’s already been stated that this will only affect newly installed WP 2.6 blogs, not those that upgrade from a previous version.
@kevin I’d love to see a reference to this if that’s the case.
I’ve searched the whole “[wp-hackers] Is disabling remote client access a good idea?” thread and don’t see any indication of that but I might have missed it. And I isn’t said in westi’s post http://westi.wordpress.com/2008/06/20/making-the-default-install-more-secure/ Nor in the comments on original ticket http://trac.wordpress.org/ticket/7157 Am I missing some resource location?
You rock. World needs more souls like you.