I just uploaded Foswiki on a USB Stick v1.1.5rc1

We’ve spent the last month fixing about 100 bugs, and security auditing 1.1.4 (and fixing several things along the way)

so this is the most stable, and safest foswiki release ever.

I’ve also fixed a few TWiki compatibility bugs that were broken in TWiki since about 2005 – so foswiki 1.1.5 is quite possibly more TWiki compatible than TWiki 5 itself!

please try it – and report any issues you find so we can work on them for the release next week

download foswiki on a USB stick 1.1.5rc1 now

A surprise move for the not quite open source project TWiki – kick people out of the dev mailing list

I guess having other people see what you’re working on is too threatening for the not-quite open source project TWiki.

It seems that allot of the developers that moved their main attention from TWiki to Foswiki have been kicked out of the public mailing list without warning, explanation or permission.

I guess its somewhat consistent with the password protection of the irc logs of the #twiki channel on Freenode (snigger).

I initially though that my mailing list password had been hacked, or maybe theirs, but thinking further, it feels consistent with the lack of deep understanding of the idea of ‘open’

Foswiki on a USB stick (updated)

FoswikiOnAStick v0.1 (running foswiki 1.0.6)

Foswiki on USB (4-Sept-2009 v0.3)

I was asked on Friday night if I could make a demo foswiki USB system, and given that its high time we did one, I started to look into it. Initially I thought this would be a great oportunity to try out the HTTPEngine work Gilmar has been doing, but we’re not quite there yet. And so, I started a quick perusal of the existing WebServer on a Stick systems. Ideally, I want to use Strawberry perl, apache, and have the server and a browser start up automatically when the USB stick is inserted into the computer.

  • MicroApache
  • Server2Go

MicroApache was the first thing i looked at, as the contact pointed out DokuWikiOnAStick, but that server doesn’t seem to have source, nor is the upstream web site there (last release seems to be 2007, so too old for Strawberry perl too) Server2Go looks nice, but as its not really free in the debian sense, I’ll pass on that unless nothing else works. XAMPP unzipped it, foswiki and did some minor configurations. unziped, removed everything except apache, added strawberry perl, and wrote a systray icon and menu system for you to control it with. TADA! FoswikiOnAStick v0.1v0.3 (running foswiki 1.0.6). please try it out.

FoswikiOnaStick syste tray menu
FoswikiOnaStick system tray menu

Instructions for use:

  1. download the Foswiki on a Stick zip file
  2. unzip it to the root of your USB key (or any drive)
  3. start the systray app, web server and browser using start_foswiki.bat (goto http://localhost/ if the browser doesn’t start) (unblock / allow apache to get through the windows firewall)

before ejecting the usb key, you need to stop the webserver by running stop_foswiki.bat yes, thats all. Please report any issues or observations to me – SvenDowideit@fosiki.com

  • the web server runs at the standard port 80, so if there is already a web server running it will fail
  • when the web server starts, it will probably be blocked by Windows firewall – every time I’ve tested, a dialog pops up, and allows you to unblock it.
  • ….


I have made no attempt (yet) to reduce the accesses to the disk – so it may use up all the blue smoke in your usbkey, cause your bits to turn green, or one of many other unforseen side effects which may or may not appear amusing if they happen to someone else. I’ve tested this on Windows7rc, Windows Vista, Windows2003server, and Windows XP – if it works for you, excellent :).

TWiki: a case study of howto lose users?

In a clear example of TWiki.NET’s new no-testing policy [1], Their star worker has yesterday un-necessarily uploaded over 300 plugins from the wrong branch in Subversion.

Rather than testing each contrib before uploading, as has been the policy on TWiki.org since the Plugins web was created, TWiki.org is now full of buggy, outdated or just plain wrong packages. The only stable option they have is to revert the uploads using rcs – as many plugins are either not up to date in subversion, or worse, are works in progress in Subversion.

Adding that to the latest TWiki 4.2.4 release, which was released with failing unit tests, and some very dubious changes:
we have already submitted to them an updated exploit that is present in 4.2.4 for the CVE-2008-5304 XSS exploit
– presumably they will release 4.2.5 in the next week?

Its a pretty sad time for those of us with users on TWiki (as Foswiki hasn’t released yet), but it has certainly spurred us along, now we need it more than we ever expected.

[1] Tom Barton: issues … impeding progress: an excessively rigorous approach to testing that actually inhibited less experienced developers from contributing code; …

Strawberry Perl rocks Windows.

if you’re working or just running Perl on Windows, drop everything, run, don’t walk, to StrawberryPerl. Adam Kennedy has not only made a real Perl for windows, he’s made a proper Perl . One where CPAN just plain works.

Even better, he’s made a Perl that you can use portably, from your USB stick, so you don’t even need to install Perl on your locked down computer.

To learn about his code, I’m building a FoswikiOnAStick distro based on his code, and then I hope to work out how to extend the concept to other platforms.

ever had Perl CPAN not work on your debian, even though you installed make etc?

CPAN, while incredibly useful, can be a pain, if you forget that you need to re-configure it after installing essential tools.

For example, if you make the mistake of setting up a basic, non-development Debian virtual machine, configure CPAN, try to use it, and on seeing ‘make’ errors like (from install Bundle::CPAN of all things) :

Running make test
Can't test without successful make
Running make install
make had returned bad status, install seems impossible
Running install for module Compress::Raw::Zlib
Running make for P/PM/PMQS/Compress-Raw-Zlib-2.012.tar.gz
Is already unwrapped into directory /root/.cpan/build/Compress-Raw-Zlib-2.012
Has already been processed within this session
Running make test
Can't test without successful make
Running make install
make had returned bad status, install seems impossible
Running make for P/PM/PMQS/IO-Compress-Zlib-2.012.tar.gz
Is already unwrapped into directory /root/.cpan/build/IO-Compress-Zlib-2.012
Has already been processed within this session
Running make test
Can't test without successful make
Running make install
make had returned bad status, install seems impossible


You install make apt-get update ; apt-get install build-essential…, only to continue to see the same errors wizz past….

CPAN really truly needs to realise that the make settings are mis configured, and tell you.

What you need to do, is to tell your cpan about it by running:
cpan> o conf init

OR, if you’ve not yet messed (configured) up your cpan, install build-essential first.

And while you’re contemplating using cpan, think hard about trying dh-make-perl instead 🙂

Ideally, CPAN should be able to realise that it can’t call make if it does not know where it is – and point this fact out, rather than making it appear as though the package being installed has an issue.

Debian TWiki repository now with 212 TWiki Plugins, Contribs, Skins and more.

I’ve just updated the Experimental TWiki and Plugins repository. It now contains TWiki 4.2.0 and 212 Plugins, Contribs and Skins that you can simply apt-get install

To use them, add the following 2 lines to your /etc/apt/sources.list

deb http://distributedinformation.com/experimental/ experimental main contrib
deb-src http://distributedinformation.com/experimental/ experimental main contrib

then type

apt-get update

to update the available packages.

you can now see all 212 packages with apt-cache search twiki-

and install (assuming you don’t have twiki installed yet)

apt-get install apache2 twiki

and TWiki Contrib installation is as easy as

apt-get install twiki-bugscontrib

You will still need to use configure to enable Plugins.

Please report your experiences to me – bugs, gripes, you name it – its a work in progress. and I need your help!

defense against the dark arts? (Cross site scripting and Cross Site forgery)

I was having a discussion with someone on IRC about how TWiki is vulnerable to Cross-site scripting and Cross-site request forgery, and we realized that there are 2 possible approaches to securing TWiki effectively (both requiring a unique magic number for all URLs):

  1. add a pre process to the TWiki::UI system, requiring a valid and unique magic, and a post process step between rendering and output to the browser
  2. use a small proxy system between TWiki and browsers to add and validate the magic
  1. is actually still risky as all scripts still are able to output directly to the browser using a =print= statement, thus giving the user urls that may not have a necessary magic in the url, or similarly for AddOns that persist in not using resthandlers.

whereas 2. abstracts the security from the application server, in much the same way as it is for ssl – goodness all round.

So – I wonder if there is such a proxy already?

There are also massive performance reasons why you should always have a proxy between browsers and heavy application servers like TWiki – this too could do with filling out.Securing TWiki is not as simple as converting all actions to POST (ie using proper REST / HTTP) because there are too many legacy conveniences, allowing GET URL’s to act upon the data. But, by delegating the securing of the transactions to an external wrapper, I think we can avoid these flaws.
see Wikipedia on Cross Site Scripting and Cross-site request forgery

TWiki 4.2.0 OpenIDUserContrib Consumer released.

I have just uploaded the OpenIDUserContrib for TWiki 4.2.0. It adds OpenID login and 1.1 Attribute functionalty to TWiki.

Currently, it disables Registration, and limits authentication to OpenID users.

It has the advantage over the OpenIDAuth apache module, that it automatically requests the User’s OpenId 1.1 attributes like Name, Email address directly from their OpenID identity.

While it trusts the user’s choice of ‘FullName’ registration attribute when displaying who made changes to topics, the TWiki topic source
actually stores the authenticating OpenID URI, thus their user details will be updated from the authentication server next time they log in.

Note that TWiki Topic based Groups are not yet implemented using this Mapper.

Future directions

  • add mixing of UserMappers to allow OpenID and ‘normal’ TWiki auth
  • turn TWiki into an OpenID identity server
  • add Safe Group definition system
  • add OpenId to TWiki’s registration process (would require openid auth first, then prefill registration details from any available attributes
    • This will require re-writing of TWiki’s inbuilt registration system
  • move the list of Known users and their mapping information from data/OpenIdUsers.txt to somewhere more scalable. (perhaps DBI)
    • combine the info TWiki uses persistently with the Session and other caching info OpenID11? uses

Net::OpenID11 (based on Net::JanRain::OpenID)

To make this work, I fixed the Perl bugs I found in Net::JanRain::OpenID, and renamed the resulting modules under Net::openID11 (as it is not OpenID2.0). I expect to upload these packages to CPAN some time soon.

If you want to take a look at the code – goto my Subversion repository