TWiki.net Kicks Out All TWiki Contributors

David Gerard noted an interesting story going down with a relatively minor project that has interesting implications for any Open Source project. He writes "Ten years ago, Peter Thoeny started the TWiki wiki engine. It attracted many contributors at twiki.org. About a year ago, Thoeny founded the startup twiki.net. On 27th October, twiki.net locked all the other contributors out of twiki.org in an event Thoeny called 'the twiki.org relaunch.' Here's the IRC meeting log. All the other core developers have now moved to a new project, NextWiki. Is it a sensible move for a venture capital firm that depends on a healthy Open Source community to lock it out?"

Comments

Wrong logs

[nuddlegg]

The logs in the posting above are not so interesting. If you need the logs of the way this was communicated to the TWiki community then have a look at http://twikifork.org/pub/Fork/TWikiReleaseMeeting2008x10x27/twiki_release_2008_10_27.log

Re:Twiki blows

[Ed Avis]

I think the most serious criticism of TWiki is its poor security track record. I used to run a site, until it was compromised by a widespread exploit uploading a PHP file as an attachment, which TWiki then saves in a directory served directly by Apache - so an attacker can upload any program he wants and it runs with privileges of the web server. In my case, it was a rather handy remote administration tool that lets you alter any file on the system (that's writable by Apache) and download the contents of /etc/passwd.

OK, anyone could get caught out by such a mistake, but the response of the TWiki developers does not inspire confidence. They added a blacklist of 'bad file extensions' so that filenames ending .php cannot be uploaded. Of course, this falls into the mistake of 'enumerating badness' and leaves you open to the next magic file extension that the developers hadn't thought of. At least in TWiki 2 the problem has been dealt with properly by using a CGI script to serve attachments, rather than leaving them to the vagaries of Apache's configuration (which is great for a website you maintain yourself, not so good for directories where anyone can upload any file with any name).

It appeared that the TWiki developers' security process was purely reactive - kludging in fixes to exploits as they were discovered - and nobody was auditing the code to discover holes before the bad guys do, or just to clean up bad smells that might or might not lead to an exploit later.

Looking at the TWiki code, it's rather a mess and doesn't seem to take the paranoid precautions you need in Perl when running system() and other interaction with the outside world - precautions particularly needed in a CGI program that's meant to be publicly accessible. I am a keen Perl programmer but TWiki is the kind of code that gives Perl a bad reputation.

That said, in an environment where you trust everybody (like a company webserver accessible only on your network) TWiki is a very handy application. I rather like the grungy way it keeps page content in RCS archives; you can hack up scripts to automatically import your existing static HTML pages into the wiki. But if I were installing a new wiki now I would use something else: preferably the kind of wiki that works by generating a set of static HTML pages and updating them on edits. That seems to have the smallest attack surface and the best performance.