easy_install http://svn.edgewall.org/repos/trac/branches/0.11-stable

Since the release of Subversion 1.5 the version of easy_install included in the Debian repository ran into a compatibility issue. Instead of working as expected it always complained:

error: Unexpected HTML page found at http://svn.edgewall.org/repos/trac/branches/0.11-stable

The problem seems to be that the SVN-Web-Output generated by Subversion 1.5+ is not being understanded by setuptools. In the issue tracker for the trac-plugin-project trac-hacks.org I found the easiest way to solve this problem. You will use the setuptools to update itself and then you won’t have problems anymore:

easy_install -U setuptools

PS: This problem also occured when trying to install plugins from trac-hacks.org since they also use SVN 1.5+.

The upgrade went fine but after it was finished trac (0.11.2.1 ) refused to start, throwing the error message

DatabaseError: file is encrypted or is not a database

According to the ticket system of trac the problem is the wrong version of sqlite which is used by trac. Sadly all my efforts to make the database useable again failed with the error message above.

After some research I discovered another way to let trac use the default sqlite3 but keeping my data alive. This chatlog states a simple way to convert your sqlite2 database to the newer sqlite3-format. Here is a quick walkthrough:

1. Install the packages sqlite (v2) and sqlite3 (guess the version )
   ^?View Code BASH

   1	aptitude install sqlite sqlite3

2. Dump the old database and convert it to sqlite3
   ^?View Code BASH

   1 2 3 4 5 6

   cd /path/to/trac-repos cd db mv trac.db trac.db.old-sqlite2 sqlite trac.db.old-sqlite2 .dump | sqlite3 trac.db chown www-data:www-data trac.db /etc/init.d/apache2 restart

And you’re done. The old database is now named trac.db.old-sqlite2 in case you need it for whatever reason. The new one is named with the default name trac.db so trac will use this one if not specified otherwise in conf/trac.ini.

I hope this tip saves you from some worries after upgrading to Debian Lenny. Keep on coding!

Today in Washington, DC, experts from more than 30 US and international cyber security organizations jointly released the consensus list of the 25 most dangerous programming errors that lead to security bugs and that enable cyber espionage and cyber crime. Shockingly, most of these errors are not well understood by programmers; their avoidance is not widely taught by computer science programs; and their presence is frequently not tested by organizations developing software for sale.

The impact of these errors is far reaching. Just two of them led to more than 1.5 million web site security breaches during 2008 – and those breaches cascaded onto the computers of people who visited those web sites, turning their computers into zombies.

[...much more...]

If you are a programmer and have the urge to make a perfect application you have to admit that this excerpt teases you. You want to know if you are better than these guys who messed up epically.

Let’s see, which errors could you have made?

Well, of course, we have the three regulars SQL Injection, Cross Site Scripting and OS Command Injection. These three are still very common although there are a various number of best practises available to prevent them.

So if you have one of these in your application you would be in good company but you will have ignored some basic rules like “Don’t trust user input!“.

Ok, moving on. What else is there password- and cryptographie-related errors are often a source of fun or blank horror. There are the ones where you should have watched the newspages like “Use of a Broken or Risky Cryptographic Algorithm“, things you should know to avoid like “Hard-Coded Password” and “Client-Side Enforcement of Server-Side Security” and things you could have tested properly like “Execution with Unnecessary Privileges” or “Improper Access Control (Authorization)“.

I know, i know – you would have done (or not done) all these things if you just had enough time for it. Well, I know the clients and I know that they don’t have the feeling for tasks like “testing”. They can’t possibly understand why such a task is taking so much time. But as reality shows it is wise to invest a big chunk of your development time into it.

So it is your tasks to make sure the client (or your boss for that matter) understands the need for testing and making “unnecessarry” code for checking user input etc. It is in both his/her interest and yours to produce an application holding up against real world scenarios and bored high school kids.

Link: SANS Institute – CWE/SANS TOP 25 Most Dangerous Programming Errors.