Well, my request for an agreeable openness went nowhere. :shrug: We have our WP 2.2.3, and it fixes the issues that Alexander and others raised. That is very good. Thanks, guys. And for the record, it was 16 days between notice and release. Very good.

Also, the news about the betas has been great. Beta 3 of WP 2.3 is the last one that’s going up, and the new version should drop on Mon 24 Sep [presuming it's ready; if they miss the date, it's not a big issue, eh?]. These are the questions I have about it, though:

1. Will 2.2.x get any support if security holes are found? 2.1 didn’t, if you’ll remember from the 2.2 release notes, but the jump from 2.2 to 2.3 is going to cause some breakage, I think, and that always slows adoption. I’d hope that a reasonable amount of security support would be provided. I’m not expecting that it’ll be kept up forever, but for say, maybe, a month?
2. Are we going to see a roadmap again? That was always fun.

Well, again we’ve got folks claiming to have found a remote SQL injection in WordPress, one that affects all versions. At least the discoverer, Alexander Concha, did the right thing: notifying the WP folks. He’s chosen not to disclose information about the hole, which means one of two things:

1. It’s bogus.
2. It’s heinous.

Because I’m weird and like to know about these things, maybe I should just ask Mark Jaquith about it, considering that he was great in discussing the WordPress “worm”. Matt’s probably still busy defending himself against straw men, anyway.

So, how about it, boys? Can you address the question? Or will it just be four weeks between notice and release without much comment otherwise? Yes, yes, yes, I imagine that I could look this up in Trac, but I’m an aerospace engineer, not a computer one; your PHP is as fuzzy to me as my Navier-Stokes equations likely are to you.

Lest you think that I am anti-Matt here, I’m not, because I think Duncan Riley was being an ass. Implicit in that comment is agreement with Mark Jaquith’s comments on the saga, especially:

Matt made a huge mistake by allowing [all the SEO-optimized crap on WordPress.org]. I was disappointed in him at the time, both personally and professionally. But he’s learned from that mistake. More than that, he’s lead efforts to warn others about that kind of behavior. That’s what the whole “sponsored themes” thing was about. That’s what the Vanilla comment was about.

See, exactly. While I have butted heads with Matt, I always find him willing to listen. That’s why I’d buy him several, several beers if we ever ended up in Houston at the same time. [Note to self: next time you're headed to JSC for work, ring Matt up.]

Back in July when I last wrote here, Matt asked:

What exactly do you want us to say?

If it’s important, then we’re working as fast as we can to get a release out and promote the heck out of it. (Think 2.1.1.) If we consider it low priority, then it waits for the next regular release, but we get raked over folks who think every little problem is the sky falling.

I think I’ll answer by saying, “What Mark posted about the WordPress Worm being bandied about is exactly what I want to see, Matt.” All I really want to see is, “Yeah, we see the bug; yeah, we’ve got a fix; no, it’s not that big of a deal.” If the bug-reporters have a disagreement with that, you’ve opened the floor for discussion, and as long as you’re cool in how you respond to the discussion and stick to the facts and don’t sling FUD about, things’ll be just fine.

There’s a vulnerability in WP 2.2.1. BlogSecurity is who brought it to my attention. After being burned by vulnerabilities before—and having gotten absolutely slammed over the weekend with HTTP requests—I worry about this security hole.

Note: Coblentz discovered the bug on 21 Jun reported the bug on 22 Jun. When did WP reply? 5 Jul, three days after a second notification. Indeed, the first notification came the same day as Matt Mullenweg raked Wincent Colaiuta over the coals.

Getting people to upgrade web software is hard. We work as best we can with hosting companies, but a consideration is that it’s best to roll several security fixes into one release. It’s not responsible to do a release if we know of another problem, so sometimes there is a lag between an initial report and a final release, not to mention the testing required of a product used as much as WP.

Indeed, it is. In fact, it’s possible that there are other security fixes in the works for WP 2.2.2, ones that have been reported to the devs and not put out on SecurityFocus. Maybe WP 2.2.2 drops tonight. But in the meantime, I have a nagging worry and no response. Unsettling.

I’ve found BlogSecurity’s WordPress Scanner to be invaluable for me; I’ve recently brought a bunch of installs up to current, but I hadn’t considered the vulnerabilities in XSS attacks on templates. But now that I know that those have holes, too, I can patch them up.

Go give WordPress Scanner a shot: all you’ll need to do to let it run is to put <!-- wpscanner --> somewhere in your template. I’d suggest putting it in the Header, where any page that WordPress Scanner comes across would have access to the statement. That way, all pages can be scanned for vulnerabilities. Just be sure to remove it after the scan is over so some black hat can’t use it against you!

It would be awesome if WordPress would include a post-upgrade scanner into the mix, checking your theme for possible holes. Upgrading WP only fixes the core files—any template you’ve used other than the default isn’t going to get fixed, and it could have a hole.

Back when I saw Wincent Colaiuta’s strident slamming of the security holes in WordPress 2.2, I commented, “I think Colaiuta overstates his case here, but the point is taken: this should have been pushed out faster.” I brought it up with Stephen at lunch yesterday, and we talked about some of the issues at play here. I think that they are:

1. Self-hosted WordPress installations not making a big enough deal to the end-user that their install is out-of-date.
2. A lack of a regimented test case suite on multiple platforms [Apache, IIS, etc.] to root out any bugs in release candidates.
3. The delay between discovery and patch release.

WordPress founder Matt Mullenweg has angrily responded. I’m a bit disappointed in Matt, because he takes every opportunity to take digs at Colaiuta’s platform of choice, rather than calmly and rationally dissecting the argument that Colaiuta made. This is perhaps understandable, as WordPress is the foundation of Matt’s career, but for him personally and WordPress in general, I wish that he’d responded with more grace.

• # The SQL problem in 2.2 requires both registration to be enabled (off by default) and the blog to be upgraded to 2.2. It is a serious problem but I’ve heard of fewer than 5 exploits from the flaw. Even if you assume there are 100 blogs for every one we heard about, that’s still an incredibly small percentage of the millions of WordPresses out there, especially considering, as Wincent points out, the problem has been in the public for a while now.
• Getting people to upgrade web software is hard. We work as best we can with hosting companies, but a consideration is that it’s best to roll several security fixes into one release. It’s not responsible to do a release if we know of another problem, so sometimes there is a lag between an initial report and a final release, not to mention the testing required of a product used as much as WP.

Those are the salient points here. The first is pretty important: the flaw was only vulnerable if you go away from WordPress’s defaults. The chances are that the users who are too lazy or unaware of the risks to keep their software up-to-date aren’t going to have changed many of the defaults. I run a community of Webloggers using self-hosted WordPress installs, and I can tell you that very, very few of them—maybe 5%—have ever done anything different than the default options.

The second point is important as well, although there’s not enough apparent testing to me—as a power user who sorta half-monitors wp-hackers, albeit with less frequency right now because I’m covered up with work—to be sure that this is fully the issue here. I don’t have a problem with a quick #.#.X release for a bug such as this, because good tools to keep your installations up-to-date exist. When 2.2.1 was released the other night, I patched 30+ installations in under a half-hour across as many domains on my server, all by hand. [The "40 minutes" comment is how long the 2.2.1 release had been out in the wild.] When I finished upgrading all my RMFO-Blogs users to 2.2.1—the re-architecture took quite some time, and had bitten me in the ass by running 2.0.2 [!] for months and getting my server 0wn3d—today, I went and upgraded about 30 users whom I’d already gotten up to 2.2 in about 15 minutes—again, by hand. I’m working on a shell script to automate this and make it much, much faster for me.

The big thing that’s come to mind for me lately is that WP needs to set an annoyance factor for release updates. At present, WP includes your version at the bottom of every page in the admin—which is good. That’s not enough, though. If you’re running an outdated installation, WP ought to bitch at you every opportunity it gets. How? There ought to be a banner at the top of every single WordPress admin page, using that lovely yellow-fade-to-blue status notice, that annoys the crap out of the user by letting them know that their installation is outdated. If I had that for my RMFO-Blogs users, I can guarantee that this would have them banging on my doorstep to do an upgrade for them. Another possibility is that any WP installation that’s out-of-date could, using WP-Cron, send a daily email to the administrator email address, advising them that their installation is out-of-date, and providing them URLs on where to download the files to upgrade and providing help pages for upgrading.

Security is a serious issue. It should be treated soberly. Matt’s angry, unprofessional response—choosing to sling a lot of mud at Movable Type—simply muddies the conversation. I had hoped for better from him. I do hope that we’ll see better in the future.

As Joe Gregorio notes, WordPress was supposed to support Atom 1.0 starting with the 1.6 milestone [which, as I recall, never happened and became 2.0]. Mark Pilgrim is frustrated, too. So am I, but this should be a surprise to exactly no one.

But being one to work within the system … there’s the new Ideas forum, and well, there’s a topic to support Atom 1.0 support in the next release. I’ve already chimed in. Go rate it up. If we all rate it up, perhaps it will become a priority. [It should be, anyway; WP is shipping to a deprecated version of a specification, something really outside the main WP ethos.]

I complained nine months ago about the lack of Atom 1.0 support in WordPress. It’s still a bit stunning to me that, a few releases later, WP still doesn’t have that support. But today, Sam Ruby pointed to Benjamin Smedburg’s plugin that generates Atom 1.0 output for WordPress. Huzzah!

I’ve gotta say that I find ticket 2972 to be wonderfully right-headed:

Currently, the most recent page (in any of the archives — dated, categorized) is page number 0. When clicking on Next Page, the url shows it being paged=1, thus page number 1. Going back even further, the page numbers increase.

However, when new posts are added, all the content in the pages shift with it.

In my opinion, it would be better if the oldest posts would be on page 1. This way, if new posts are added, consequently new pages are added. AND the content of the pages stay the same.

It’s all about future-proofing, and that’s a very, very good thing.

After I lauded software that publishes HTTP 304-aware feeds, Scott tells me that IJSM.org’s feeds are no longer 304-aware. UHOH!

So I decide to do some investigation. I have a variety of WordPress installations at various revision levels across the server I administer. [Bad, I know!] Anyhow, my results were as follows:

v2.0 RSS2 feed shows up as returning 304. v2.0.1 RSS2 feed shows up as returning 304. WordPress.com RSS2 feed shows up as returning 304. v2.0.2 RSS2 feed does not return a 304.

I have checked the /rss/, /comment/, and /atom/ feeds for IJSM.org and they also show no 304 headers returned.

The comments feed for the 2.0.1 install I have returns a 304 as it should.

– Trac.WordPress.org ticket 2597

Seems that the issue definitely showed up in the 2.0.1—>2.0.2 transition.

I don’t know if this is related to the security fixes of 2.0.1—>2.0.2; if so, I’m okay with it. I’ll take the bandwidth hit on my box over the probability of my box being 0WN3d. That said, this is still an issue.

– ibid.

I really and truly mean that. I’ll take the bandwidth penalty! … for now. Eagle-eyed readers will suspect that I’ve future-posted this entry; indeed, I have. It was written Friday night to give the WP guys 24 hours’ notice. I figure that I owe them that.