Welcome to the personal weblog of Wincent Colaiuta
This is my personal weblog where I write things that aren't always related to my business. If you're looking for information about my products please go to wincent.com, and for official news see here. Shortcut to this weblog: colaiuta.net.
April 3, 2007
WordPress 2.1.3 but not for me
After a cracker broke into the WordPress server last month and replaced the official download with a trojan (an incident described by the WordPress public-relations team as a "systems issue") I decided to give WordPress the flick, forever (see "Removing a WordPress 2.1.1 installation and replacing it with a static mirror").
Today brings another update, once again security-driven.
This update is highly recommend for all users of both branches.
Translation: upgrade immediately or get owned.
These releases include fixes for several publicly known minor XSS issues, one major XML-RPC issue, and a proactive full sweep of the WordPress codebase to protect against future problems.
The WordPress team needs to change the way they work with respect to security. This is a very popular, public-facing web application. Instead of springing these forced security updates ("upgrade now or else") on the masses they should do three or four things:
- Adopt a regular, public update schedule for security updates so that people can plan and be ready for security updates. Something simple like "first Tuesday of every month".
- Have a core-team-only security branch which is merged into the publicly-viewable branches only just before release. More on this point below.
- Implement a mandatory review process in which every single check-in must pass a security review by another team member; this security-specific review should be in addition to any existing review procedures they might have (emphasis on the might).
- Appoint a security officer whose responsibilities include a coordinating regular, pro-active audits of the code base.
Now to address the second point above; I love the open source development model and I think it's great to develop stuff out in the open. But when it comes to security fixes for vulnerabilities need to be kept secret until they are released. With WordPress we currently have the worst of both worlds: throughout the entire development cycle attackers can monitor the WordPress trac for vulnerability reports and the corresponding fixes and start working on exploits; meanwhile, users are exposed to risk and then on release day told to upgrade as quickly as possible or face the consequences.
They need to get their security fixes on a private branch. This is not a desktop application like Firefox. If you're on holiday and upgrade your browser a week late then it's no big deal; but if you're a WordPress administrator and an exploit gets released while you're on a beach in Santo Domingo then your risk is many times greater. The dealing of security issues in the open followed by sudden, irregular releases without proper advance notice for scheduling just makes this problem worse.
The WordPress security track record has been appalling in the past so we can safely assume that vulnerabilities will continue to be discovered.
We have taken dozens of additional precautions with the servers and systems that run WordPress.org and they appear to be working well, despite hundreds of hack attempts after we publicly disclosed there had been a problem. We are also now aggressively monitoring all downloads for any changes or modifications, and we are confident the same type of problem wonât happen again.
My response: too little, too late.
More Miscellaneous articles
Posted by wincent at 12:32 PM
March 30, 2007
Be assertive
Most imperative programming consists of lists of instructions, where subsequent instructions tend to depend on the results of previous instructions:
01 get A
02 pass A to B, producing C
03 get D
04 add C and D to get E
05 ask E for F
06 ask F for G
07 print G
What do you do if you run the pseudo-code above but it doesn't print G like you expected?
The obvious answer is that you back-track: you find out why F didn't return G. Part of that will involve confirming that you actually did get F from E like you asked. If you're unlucky, your troubleshooting process may require several iterations and you'll end up going all the way back to the first line and discover that the problem is occurring when you try to get A.
Fail early
Instead of working backwards a much better approach is to start at the beginning. You want to fail early; or to put it another way, in the event of a failure you want to find out about it as early as possible. You want failure notifications to be produced as close to the site of the actual failure as possible, so that you can find the causes more quickly.
The way you do this is with assertions.
Read full article
More Development articles
Posted by wincent at 12:11 PM
March 28, 2007
You can run but you can't hide; why even run?
Spammers.
The scourge of the Internet. We have so much to thank them for:
- The waves of junk mail pouring into our inboxes.
- The painful challenge-response systems that stop us from sending legitimate email.
- The DNS blacklists that make sending mail from a dynamic IP unfeasible.
- The throw-away email addresses that we register to protect our real address.
- The forced migrations from one spam-inundated account to an inevitably to-be-inundanted other.
- The greylists that slow down our legitimate outgoing messages.
- The moderation that dampens discussion lists.
- The virtual ruination of NNTP, in my view largely spared only by Google and their groups gateway.
- The endless confirmation emails that we must work through in order to register at new sites.
- Email addresses that you can't click on, but that you have to "translate" from based on what you see in an image or some kind of code.
- Companies that you can't email even though you're a paying customer.
I could go on but by now you're getting the idea. And that's only in the realm of email; spammers have also done and are doing their very best to ruin forums, weblogs and every other online space.
Well, I'm sick of running. I'm sick of hiding. I don't want my customers to have to jump through hoops in order to contact me. I used to think that controlling spam required proper server-level measures (blacklisting, filtering, proper sendmail configuration) combined with client-level filtering and a big dose of obscurity (email hiding) thrown in.
For a long time I tried to keep my email address off the site, and in the places where I did show it I used cryptic equivalents like "win at this domain". I tried to channel all contact through a web contact form. I even migrated from my old address win@wincent.org to win@wincent.com because the old address was receiving too much spam.
Well, I'm a bit tired of all that. I think it sends the wrong message to customers. It really means, "Spammers, I don't want to hear from you", but it can actually make customers feel like I'm saying, "Customers, I don't want to hear from you". This isn't true. I do want to hear from customers. Customer feedback helps to improve products and keeps one motivated. Even the "bad" types of customer contact (complaints, "silly" questions) are in indication of things that you should be doing better (ways your documentation could be improved, ways your interfaces could be changed so that those kinds of questions don't crop up).
I still believe that server-side measures and client-side filtering are very important (see the Knowledge Base article "Combating spam") but I've decided to throw the obscurity part out the window. If you've been reading this weblog of late you'll be aware of the moves towards openness and transparency that I've been making; this new attitude towards email and spam is just another step.
As part of this I have plans to revamp this site and make it more open and integrated. Yes, my initial dislike for all things Web 2.0 has settled down and I'm planning on taking from it the best bits and leaving out the bits I don't like. Once the revamp is done you'll still find a contact form for those who can't send email, but you'll find my email address writ up front and large for those who want to get in touch quickly and easily via email.
Please contact me (win@wincent.com) if you have any comments or suggestions.
More Opinion articles
Posted by wincent at 1:10 PM
March 25, 2007
Synergy Advance build number changes
As of today the build numbering system used in Synergy Advance has undergone a once-off change and I wanted to explain here to help clear up any confusion that it may cause.
The changes are described in full in the "Build numbers" article but here's the brief overview:
Previously Synergy Advance used a build number scheme that incremented by 1.0 for each release build and 0.1 for each debug build. So the last publicly released version (0.4) had a build number of 1192.0.
As of today, I've started using the Subversion revision number instead because this is non-arbitrary and exactly identifies the source code used to produce the built product. That means that as of right now the current build number is actually 399, corresponding to revision 399 in the Subversion repository. By the time 0.5 comes out (hopefully quite soon) that revision number will have jumped up a few notches. Build numbers like "399+" indicate that the build was produced from the code corresponding to revision 399 in the repository plus some local modifications that haven't been checked in yet. In reality only I will see build numbers like that with plus signs on the end; customers will always see straight build numbers.
I'm making these changes to provide increased transparency in the development process. You can keep your eye on the Subversion Log (a live list of checkins) and see exactly which code changes correspond to the build that you're using.
More Miscellaneous articles
Posted by wincent at 5:05 PM
March 21, 2007
Synergy one-day sale: licenses for $4.50
In conjunction with MacUpdate, Synergy will be available for sale tomorrow for the steal price of only $4.50.
The sale is for one day only (22 March 2007), starting at midnight (US Eastern Time).
Once the sale starts you'll be able to make your purchase here.
More Miscellaneous articles
Posted by wincent at 6:16 PM
March 20, 2007
Involuntary reboot log #8
You could argue that this one is my fault but I like to blame it on the Mac OS X dependence on NetInfo for user information.
I was trying to find out why another machine on my local network was continuously hammering my machine with packets. Well, not exactly hammering but generating a steady 5 to 10 kilobytes of traffic per second. It was as though my machine was being used as a gateway.
So I tried to rule things out one by one. Internet connection sharing was turned off. I wasn't running Tor or Privoxy. I ended up quitting basically everything and the traffic continued. I then tried to block the offending IP address using ipfw and the traffic still continued.
sudo ipfw add deny ip from 192.168.1.34 to any
sudo ipfw add deny ip from any to 192.168.1.34
I have no idea why this didn't work but I continued to see TCP traffic. Variations on these rules didn't seem to work either. I then committed the mistake that required the reboot:
sudo ipfw add deny all from any to any
That stopped the traffic all right but it stopped everything else, including NetInfo lookups, and that meant that the following didn't work:
sudo ipfw delete 100
Nothing sudo worked because it couldn't look up my credentials and complained that user ID 501 didn't exist in /etc/passwd. So I tried to reboot and Mac OS X decided to hang forever at the blue screen, requiring a hard reset. Sigh...
Right now performing my customary boot-from-DVD and repair with Disk First Aid trick... One of the drives claims to need minor repair. Another hour down the gurgler...
Read full article
More Involuntary Reboot Log articles
Posted by wincent at 6:38 PM
March 14, 2007
Planned changes to development model
I've commented elsewhere that I plan on approximating a continuous integration model of development in future releases of Synergy Advance (and all my products in fact).
In my comment I wrote:
After several months of positively "seismic" changes to the codebase (massive upheaval) the code is finally back in a buildable state... Almost every file has been touched, every project, every target... thousands of lines of changes and major structural reorganization. A lot of this has been mind-numbing work, a necessary evil to enable future growth, but with no short-term reward (no build-and-run gratification).
But it finally runs again after hundreds of hours of the most boring type of development work there is. Still some issues to iron out, but my plan now is to keep it in a very-near-to-release state from here on; that is, I will be approximating the "continuous integration" model of development, where the software will always be in a releasable or almost-releasable state. At any point in time I should be able to decide, ok, I want to package up a release for tomorrow, and be able to do it.
Read full article
More Development articles
Posted by wincent at 1:48 PM
March 13, 2007
Using MediaWiki markup from within MovableType
I like to keep an eye on Gervase Markham's weblog. Today he published an article about converting MediaWiki markup to HTML.
It turns out that that is something I've wanted to do for some time now. Well, not so much the general markup itself (we already have Markdown for that) but the wiki links where you can write words or phrases surrounded by double square brackets and they'll be turned into links to articles on the wiki.
Thanks to Markham's article I learned about the Text::MediawikiFormat module, which is a Perl module that can convert text written using MediaWiki markup to HTML using a simple API:
my $converted = Text::MediawikiFormat::format($text);
I use MovableType to write these weblog entries and I have often wanted to be able to type a wiki-style link to "something" in an entry and have it link to the "something" page on the Knowledge Base. About 20 minutes of learning the MovableType API later I have a nice little plug-in that allows me to write entries like this one and link to the wiki with ease. It's literally one line of meaningful code; the rest is just plug-in registration and other bookkeeping. The only limitation I've found so far is that it doesn't seem to support the "nowiki" and "pre" directives in the same way that MediaWiki does (see tickets 25417 and 25418).
See "Writing a WikiText plug-in for MovableType" for the not-very-gory details.
More Miscellaneous articles
Posted by wincent at 5:32 PM
Improved Google search and AdSense
I've made some minor changes to the Google-powered site search today, namely, adding a Wincent logo and header to the search results:
I've also added some Google AdSense advertising to the Knowledge Base wiki. I don't plan to ever put advertising on the commercial parts of this site (the product pages, for example) but I have no problems with adding a small amount of non-intrusive ads to a section like the Knowledge Base which is a free resource. I'm motivated principally by curiosity; I want to see how AdSense works from the side of the website operator. I suspect that on a site like this one that receives only modest traffic that the income will be insignificant, possibly even nil, but I'd still like to give it a try and see what happens.
You can read this article for more information on how to add AdSense to a MediaWiki installation.
Read full article
More Miscellaneous articles
Posted by wincent at 4:15 PM
March 12, 2007
A call for help: Bansshee
Update, 16 March 2007: Charles Steinman has kindly donated to cover the registrations for all three domains (dot-org, dot-com and dot-net). I'm leaving the original text of the post below for the historical record.
Ooooh, I hope the title of this post isn't too dramatic. I just got a GoDaddy renewal notice for the Bansshee domain names (bansshee.com, bansshee.net, bansshee.org) and I'm looking for donations to fund their renewal.
I've written before about how I don't want to cave in to GoDaddy's "bait and switch" pricing scams (previous articles: 1, 2, 3, 4, 5). So at the start of this year I basically took the decision to let all non-essential domain names I have registered with GoDaddy expire. The Bansshee domain names are among the affected ones.
About Bansshee
Bansshee is a lightweight daemon written in Perl designed to thwart dictionary-based SSH brute force attacks. It is free software released under the GPL. Given that I don't actually make any money out of Bansshee (no donations so far, although I have received code-contributions from two kind souls) I'm asking if anyone would like to step forward and make a donation to cover some part (or all) of the renewal costs for these domains. The domains aren't essential for the continuation of the project (the software will continue to be hosted here) but I'd like to continue providing them as a convenience for users if I can.
If the donations cover the costs then I'll transfer the domains away from GoDaddy to another register, probably Joker. The highest priority will be bansshee.org, followed by dot-com and finally dot-net. Take a look at their price list if you'd like to donate. You can send your donations via PayPal using this link.
More information about Bansshee can be found on the project page and in the two articles (1, 2) that I wrote while developing it.
Bansshee itself has been running on this server shielding it from the brunt of brute-force SSH dictionary attacks for almost a year now. It was deployed in April 2006 and then tested up until public release in October 2006 without skipping a beat. As an example of its reliability, it's been running without interruption for 141 days now (since the last server reboot for an operating system update). Not bad for a little daemon written in Perl!
I don't really know if anyone will step forward on this one; regular readers of this weblog are familiar with my disappointment in the viability of open source software for extremely small businesses like my own. I'd love someone to surprise me.
More Miscellaneous articles
Posted by wincent at 3:25 PM
March 8, 2007
Bizarre display glitch
The most bizarre drawing glitch I've ever seen, provoked by trying to resize the frontmost Safari window; another, unaffected Safari window is visible in the background:
Not sure if it's a bug in Safari, Mac OS X, or both.
More Mac OS X articles
Posted by wincent at 2:34 PM
February 22, 2007
Goodbye parity, hello superiority
With memoizing:
235 specifications, 0 failures
real 0m7.580s
user 0m7.035s
sys 0m0.347s
Without memoizing:
235 specifications, 0 fail