No more CMS....back to static html

After tiring of a second CMS, the time came to rethink the website and now you can see the results.

A Content Management System is great - you can add new text and pages using your web browser and all the site layout is already there. The problem with CMSs is that to make the site interactive, a lot of functionality must be added which exposes a lot more functionality that can be exploited. Before Christmas I was using b2evolution (v0.9.0.11), a blogging CMS, which I had to remove because of a constant bombardment of robots trying to add links for tracebacks to the site. I believe this vulnerability was fixed in later versions but I used the opportunity to try e107 (v0.6172). e107 is all full featured CMS, built with PHP like b2evolution, that has lots of functionality. However, it has vulberabilities of course and these were expoited before I could upgrade to the latest version.

To me, the problem seems to be that using a CMS requires almost constant upgrading to the very latest version. This is ok if you want to upgrade several hours a week to a website but not ok if the website is a background task. So I've decided to go from using a CMS i.e. GNU/Linux, Apache, PHP and mySQL to using plain old XHTML and CSS i.e. GNU/Linux and Apache. This will definitely reduce the attack vectors and hopefully reduce the attacks. Time will tell and remembering that nothing is 100% secure.

There is a great site called Open Source Web Design where web designers showcase their templates and designs - its like Sourceforge for designers. I found this design that was put together by a guy caled Andreas Viklund. Its pure XHTML and CSS and W3C compliant.

On a last note, if you are interested in trying out some CMSs, this site is great - it lets you try out the CMS without downloading anything.

FRET v0.0.6 - here at last

Arriving some weeks later than planned, the new version includes new functionality, several bug fixes and refactored code.

I've added two new commandine options: --phase and --scan, that allow the user to specify a particular range of tests to run. Several bugs have been fixed and the Group code (and concept) is now gone - this makes the code size more manageable and hasn't removed any currently used functionality.

I also had a chance to analyse the performance of FRET for the first time. As expected, the ScanGrind analysis (it looks for data that is common to two of more files) is the major contributor. Its analysis duration grows exponentially with file size. This can unfortunately lead to very long durations for files over 1 MB - I estimated that it takes 27 hours to analyse two 1.7 MB files. This is not unexpected although I am sure there is room for improvement in the algorithm. However, currently the algorithm is totally brute force - it compares the start of one file with the end of another etc. and I don't think that this makes sense when examining file formats. A more intelligent approach would be to divide a file into zones, maybe based on already detected Grams, and then to look for commonalities between those zones.