WordPress 2.6 – Causing waves on Mars: The XMLRPC controversy

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.