Archive for the ‘On WordPress’ Category
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:
- 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?
- Are we going to see a roadmap again? That was always fun. 🙂
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:
- Self-hosted WordPress installations not making a big enough deal to the end-user that their install is out-of-date.
- A lack of a regimented test case suite on multiple platforms [Apache, IIS, etc.] to root out any bugs in release candidates.
- 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.
Kudos to WordPress for doing well in Joe Clark’s assessment of WordPress against the Authoring Tool Accessibillity Guidelines. The main complaint seems to be against the WordPress toolbar in the Write/Edit page in the admin, which I would argue needs further development. After all, there are cases where you want i elements instead of ems: for example, any proper title that you choose to italicize really isn’t something that you’re emphasizing; you’re just using italic type to alert the reader to the presence of a proper title.
The easiest way to summarize Clark’s finding is this: WordPress’s core commitment to producing standards-compliant markup makes it generally very accessible. The WP development crew should read Clark’s assessment, feel a sense of pride, and heed the minor suggestions and constructive criticisms provided.
The debacle that has been the WP 2.0 release cycle to date—look at the comments on Owen’s “Why aren’t you upgrading?” entry if you haven’t seen the furor—has just driven home to me the need for a structured testing program for WordPress releases.
I especially want to point to Craig Hartel’s comment, which is what inspired me to write this entry today:
I see this same discussion after every major release, and always the answers are basically the same.
What can we do to address this repitition? I suppose one major thing would be to establish a formal testing program. I would certainly participate in that, if I knew how. I feel like I’m a WP user that kind of falls through the cracks within the WP community. I know enough to get myself into, and usually, out of trouble, but I can’t code my own plugin or do much more than change some settings within an existing one.
I’ve been with WordPress since the pre-1.0 days, and I think its development has been amazing. Sure, there are plenty of things to be critical about, but what good project doesn’t have things to work on?
Somebody, please offer your skills to mentor users like me who want to gain more knowledge and understanding to help contribute to a fantastic open-source community.
FWIW, I’ve never really hesitated to upgrade, and I’ve never really had any major issues either (knock on wood). My biggest concern with WP has always been security, and I feel that by and large, security issues have been dealt with in a reasonable fashion.
Upgrading for its own sake is not a good reason, IMO, but I did just that for WP 2.0, and I’ve not regretted it.
I’m right there with Craig—I’d help if I knew how. Help me help you!
Here’s what WordPress needs in terms of a testing system:
- A release candidate period.
If we had an RC period of, say, a week for users to download, install, and run test cases on a build of WordPress, then note all the bugs, things would be a lot better.
What this takes, though, is a willingness to call for an RC, open it up to testing, and a specific bug-reporting environment for that RC alone. Nightlies and all can happen while the RCs are out, but you have to encourage your RC testers to stay away from the nightlies while they’re doing RC testing—everyone needs to be on the same page.
- A set of test cases to run against.
What’s broken WP in the past? I18N? HTML characters? Write up a fault tree. List every core feature to be tested, and give people targets to shoot at. If you have a ton of users running a bunch of test cases on all your features, you’ll likely find all the bugs you’ve got in there, including those that are server configuration-dependent.
Since I mentioned config-dependencies, I think a lot of WP users and testers are on a LAMP structure, but I know folks run WP on various versions of PHP, MySQL, and sometimes on HTTP servers other than Apache. So, let’s encourage the people that have bugs in the past to help with testing! They’ve got an interest in helping you.
- Patience and understanding on everyone’s part, and no date-driven releases. Goals and targets are great things, but sometimes you need more time.
What else is needed in coming up with a good test suite for testers? Testing needs good structure for us to have a clean .0 release.