22 ms·

They forgot: Optimize for security.

by jcapote 16y ago

jusob 16y ago
That was my first thought: they are so many security flaws in Woedpress, how can it be a good example? Check the latest advisories on SecurityFocus.
jerf 16y ago
I think it's worth pointing out that while I suspect you may have intended that as pure snark, there is a deeper point lying under it. Assuming this continuous deployment is something like "developer picks up bug, hacks out whatever solution works, deploys it five minutes later", then you are punting on any issue that may require a bit more introspection. This most notably includes security, but there's other things that this procedure will fry too, like longterm maintainability and such. Not to mention offloading QA onto your customers, which may work for a free webservice holding nothing of particular value but hardly works for everybody. (And I hope they have good backups.) With this logic, it's perfectly fair to point out that WordPress's security record is absolute shit (tptacek: "There are unforced errors in Wordpress. Every web application will have a cross-site scripting mistake. It takes a special one to have "anonymous commenter" -> "admin" privilege escalation, or executable style templates." - http://news.ycombinator.com/item?id=1328583 http://news.ycombinator.com/item?id=1328583) and it's fair to conclude that this "We systematically and deliberately fail to check our code before deploying it!" approach to development may be a contributing factor. Now, nothing stops you from implementing "take bug, code solution, run it through code review and QA, deploy" on a patch-by-patch basis, but I have a hard time imagining making 20 releases a day with that procedure, so I'm assuming that's not what they are doing with some reason. Basically, what I'm saying here is that hearing WordPress advocate this model is a strong argument against it. If they honestly think it's not costing them anything, or even just a net benefit, then I call their judgment into question. Or perhaps rather, further into question, since I think their security track record was already calling their judgment into question.
- tonischneider 16y ago
  Not surprisingly, I disagree. First of all, you are lumping WordPress the open source software and WordPress.com the hosted service together. My post is about WordPress.com which uses the continuous deployment model and has a very solid security track record (as good or better than any other large scale web service like Facebook, GMail, etc). Also, our fast deployment model helps to very quickly fix whatever problems there may. Finally, though I can't speak for WordPress.org because it's separate from Automattic, they have developed a very effective model of responding to security issues and auto-notifying and -updating people.
  - jerf 16y ago
    "First of all, you are lumping WordPress the open source software and WordPress.com the hosted service together." Yes I am, and I apologize. I did not realize there was much of a distinction. I would edit away much of my message now if I could. But... "Also, our fast deployment model helps to very quickly fix whatever problems there may." Security problems do not work that way. Rapid deployment does not recover your user database that the hacker got, just as one example. Rapid deployment may close XSS holes, but doesn't undo the damage they did while open. And you don't need rapid deployment to close XSS anyhow, historically lots of people have managed that without rapid deployment. I still see it as potentially beneficial on some fronts but an enormous risk on other fronts I care about a lot.
  - rm-rf 16y ago
    Is wordpress.org a different code base?
- kareemm 16y ago
  > Not to mention offloading QA onto your customers, which may work for a free webservice holding nothing of particular value but hardly works for everybody. Funny, when I worked at ESPN.com this is exactly what we did. When I first started, I was horrified. But you know what? Traffic and revenue still grew, and users didn't seem to mind. Deploying quickly gave us an incredible speed advantage that allowed us to change and respond to problems and new opportunities.

They forgot: Optimize for security.

by jcapote 16y ago

They forgot: Optimize for security.

jusob 16y ago

That was my first thought: they are so many security flaws in Woedpress, how can it be a good example? Check the latest advisories on SecurityFocus.

jerf 16y ago

I think it's worth pointing out that while I suspect you may have intended that as pure snark, there is a deeper point lying under it. Assuming this continuous deployment is something like "developer picks up bug, hacks out whatever solution works, deploys it five minutes later", then you are punting on any issue that may require a bit more introspection. This most notably includes security, but there's other things that this procedure will fry too, like longterm maintainability and such. Not to mention offloading QA onto your customers, which may work for a free webservice holding nothing of particular value but hardly works for everybody. (And I hope they have good backups.) With this logic, it's perfectly fair to point out that WordPress's security record is absolute shit (tptacek: "There are unforced errors in Wordpress. Every web application will have a cross-site scripting mistake. It takes a special one to have "anonymous commenter" -> "admin" privilege escalation, or executable style templates." - http://news.ycombinator.com/item?id=1328583 http://news.ycombinator.com/item?id=1328583) and it's fair to conclude that this "We systematically and deliberately fail to check our code before deploying it!" approach to development may be a contributing factor. Now, nothing stops you from implementing "take bug, code solution, run it through code review and QA, deploy" on a patch-by-patch basis, but I have a hard time imagining making 20 releases a day with that procedure, so I'm assuming that's not what they are doing with some reason. Basically, what I'm saying here is that hearing WordPress advocate this model is a strong argument against it. If they honestly think it's not costing them anything, or even just a net benefit, then I call their judgment into question. Or perhaps rather, further into question, since I think their security track record was already calling their judgment into question.

tonischneider 16y ago
Not surprisingly, I disagree. First of all, you are lumping WordPress the open source software and WordPress.com the hosted service together. My post is about WordPress.com which uses the continuous deployment model and has a very solid security track record (as good or better than any other large scale web service like Facebook, GMail, etc). Also, our fast deployment model helps to very quickly fix whatever problems there may. Finally, though I can't speak for WordPress.org because it's separate from Automattic, they have developed a very effective model of responding to security issues and auto-notifying and -updating people.
- jerf 16y ago
  "First of all, you are lumping WordPress the open source software and WordPress.com the hosted service together." Yes I am, and I apologize. I did not realize there was much of a distinction. I would edit away much of my message now if I could. But... "Also, our fast deployment model helps to very quickly fix whatever problems there may." Security problems do not work that way. Rapid deployment does not recover your user database that the hacker got, just as one example. Rapid deployment may close XSS holes, but doesn't undo the damage they did while open. And you don't need rapid deployment to close XSS anyhow, historically lots of people have managed that without rapid deployment. I still see it as potentially beneficial on some fronts but an enormous risk on other fronts I care about a lot.
- rm-rf 16y ago
  Is wordpress.org a different code base?
kareemm 16y ago
> Not to mention offloading QA onto your customers, which may work for a free webservice holding nothing of particular value but hardly works for everybody. Funny, when I worked at ESPN.com this is exactly what we did. When I first started, I was horrified. But you know what? Traffic and revenue still grew, and users didn't seem to mind. Deploying quickly gave us an incredible speed advantage that allowed us to change and respond to problems and new opportunities.