TWiki.org upgrade to TWiki 4.0
TWiki.org is in the process of being upgraded to TWiki 4.0.
Tasks & Status
Decision on session tracking
With cookies and IP tracking (for security)
Upgrade all TWiki web topics to Dakar
All current TWiki web topics need to be upgraded to the TWiki 4.0 content, enclosed properly in header/footer & START/ENDSECTION as documented in
DistributionDocument.
Convert 20K user home pages if necessary
TBD if to convert existing home pages. The new registration uses forms to keep the data, splits firstname and lastname, and there are additional changes. This makes it impossible to run meaningful reports with user home pages in the old and new format. If we upgrade, the question is what do do with the many missing/obfuscated e-mails etc.
--
Contributors: PeterThoeny
Discussion
We need to discuss & decide on security implications of cookie based session tracking. For example, as a site admin I work a few hours a day on TWiki.org. An intruder would not need to wait long to see my activity and steal a cookie session (in case possible.)
--
PeterThoeny - 20 Mar 2006
Can anyone sketch the security implications? Of course we need to make sure session ids can not figure in URLs (otherwise general access to url logs like i.e. awstats need to be closed, asap :-)), and that noone can read /tmp.
But except from that? I'd say
CGI::Session is very secure in itself.
Didn't see any mention on which login mechanism we're aiming for, but if its the template login that is going to be used, known security measures apply (for protection against
cross site scripting).
I am not familiar with current setup, but unless there's some kind of IP spoofing protection currently in place, current security could be a lot worse than session tracking will be.
--
SteffenPoulsen - 21 Mar 2006
It is essential to performance and daily use for users that we have the right combination of security and usability. IMHO using Sessions is OK as long as it is combined with IP matching. It is for sure more safe than the simple IP maching we have today on twiki.org. Sessions and quite normal in most websites today and it would take an attacker a great deal of effort to both get a session ID (not really easy) and spoof your IP. If you just authenticate for each page your password is sent in clear unless you buy a certificate and run https. And getting your password is worse because that does not have to be matched with IP address.
The settings I am recommending for a public Internet site (and I am using on my Internet Motion TWiki) are as follows - with focus on security.
Security
- {UseClientSessions} ON
- {Sessions}{Dir} /tmp
- {Sessions}{ExpireAfter} -21600. Use negative value!! Means a lot to performance on a busy site like twiki.org. This must be combined with a crontab entry like
00 0,6,12,18 * * * root cd /usr/local/apache2/twiki/tools && perl -I /usr/local/apache2/twiki/bin tick_twiki.pl
which cleans our session files every 6 hours and does additional cleanout of stale lease files from when a user edit and back out. Interval could be decreased to 3 hours.
- {Sessions}{IDsInURLs} OFF - Users today all accept cookies. Turning this off prevents people from sending URLS including a valid session cookie ID in the URL.
- {Sessions}{UseIPMatching} ON - This prevents an attacker from easily using a session cookie.
- {Sessions}{MapIP2SID} OFF - Important to turn this off.
Authentication
I prefer Apache login because it allows IE to better remember password. But Template login looks much much better and think this should be chosen for the image of TWiki
- {LoginManager} TWiki::Client::ApacheLogin
- {DefaultUserLogin} guest - Default
- {DefaultUserWikiName} - Default
- {AdminUserWikiName} TWikiAdminGroup - Default
- {SuperAdminGroup} TWikiAdminGroup - Default
- {UsersTopicName} TWikiUsers - Default
- {MapUserToWikiName} OFF - We use WikiName to login
- {AuthScripts} attach,edit,manage,rename,save,upload,viewauth,rdiffauth - Default. Any additional plugins?
- {AuthRealm} Use value which we use today
Passwords
- {PasswordManager} TWiki::Users::HtPasswdUser
- {Htpasswd}{FileName} Absolote path to data directory
- {Htpasswd}{Encoding} Crypt - probably also what is used today. We will want to reuse password file
- {Register}{AllowLoginName} OFF - We use WikiName to login
- {Register}{HidePasswd} ON - Default
- {Register}{NeedVerification} ON - Obvious choice to limit spam. This means new users must use valid password and an additional reason to set HidePasswd ON.
Paths
- {SafeEnvPath} /bin:/usr/bin - Default
Miscellaneous
- {DenyDotDotInclude} ON - Default
- {INCLUDE}{AllowURLs} OFF - Could break a few things but I doubt it is important things.
- {AllowInlineScript} ON - Default
- {UploadFilter} (?-xism:^(\.htaccess|.*\.(?i)(?:php[0-9s]?|phtm[l]?|pl|py|cgi))$) - Default
- {NameFilter} (?-xism:[\s\*?~^\$@%`"'&;|<>\x00-\x1f]) - Default
- {ForceUnsafeRegexes} OFF - Default
- {GetScriptUrlFromCgi} OFF - Default
- {RemovePortNumber} OFF - Default
- {AntiSpam}{EmailPadding} PLEASENOSPAM - Should be changed now and then to avoid that the email harvesters are programmed to expect the same static value.
- {AntiSpam}{RobotsAreWelcome} ON - We want Google to index the TWiki so we can use this for searching. We are many that use this often.
Log Files
I assume we log everything which is default
Localisation
It will look good to show the new multilingual features. BUT this slows down TWiki by adding easily 30-50% extra execution time. And this gives a bad impression. I recommend turning it off for performance.
{DisplayTimeValues} gmtime - We are an international site and should use GMT
Mail and Proxy
Default values except.
- {SMTP}{MAILHOST} should either be an SMTP server that allows us to connect OR we use our own sendmail and then the value should be 'localhost'
- {SMTP}{SENDERHOST} twiki.org
Plugins
Default plugins all enabled.
- However Wysiwyg can still cause trouble but it is an important showcase and new feature. We should probably enable it.
- BlackListPlugin is a must
- Plugins}{ChartPlugin}{Enabled} has always been there
- {Plugins}{TWikiDrawPlugin}{Enabled} has always been there
- Whatever extra.
When we install TWiki we should run the script
tools/upgrade_emails.pl
so that all email addresses get added to the htpasswd file. This enables users to remove or heavily distort their email address on their home page. We need to consider if we keep them visible or hide them if we make a convertion script for user pages. I would hide the email addresses. Our email address padding is not adequate any longer. We can send an annoucement about the upgrade of twiki.org and add in this that users can choose to remove their email addresses from display simply by editing their home page.
I hope all this will be a help in setting up twiki.org for 4.0.2
--
KennethLavrsen - 05 Apr 2006
Upgrade all TWiki web topics to Dakar ??? Dakar does that seamlessly as long as the old topic with tabs is format 1.0 in the header. So do NOT use the same data directory for Cairo and Dakar in an overlapping period. That will not work well
--
KennethLavrsen - 05 Apr 2006
Ugrade of TWiki web topics to Dakar is needed to address
DakarDocumentationModelIsBroken. I am already making good progress on it.
--
PeterThoeny - 17 Apr 2006
Updated security proposal to Apache auth as agreed on Edinburgh meeting.
--
KennethLavrsen - 17 Apr 2006
TWiki.org runs TWiki 4.0.2 since 2006-05-27. Please report any problems you might encounter here.
The system web is temporarily set to the
TWiki04 web. Once all important system topics of the
TWiki web have been updated to TWiki 4 I will switch
%TWIKIWEB%
back to the TWiki web.
--
PeterThoeny - 27 May 2006
This may be because of the previous bullet, but I'm running into lots of pages with broken links over in the Plugins area, for example:
--
DougClaar - 31 May 2006
Thanks Doug, those links are fixed. They should point to TWiki webanyway, not to %TWIKIWEB%.
--
PeterThoeny - 01 Jun 2006
There is a report in
UpdateInfoPluginDev that .tgz files are delivered with the wrong mime type. I fixed the data/mime.types file, and fixed the core,
Bugs:Item2427
--
PeterThoeny - 06 Jun 2006