therning.org/ magnus

I put up Epilicious on GnomeFiles just a few days ago and it didn’t take long for the first patch to come in. I have a few ideas for improvements, mostly regarding user feedback. I just have to find the time.

I just signed the pledge for a British EFF. I encourage everyone living in Britain to do the same. There is some additional info here and here.

For a project that I’m considering I’ve spent a few hours looking into using Python to access GMail. There’s a nice Python library called libgmail, but it’s a bit overkill since all I want is to see how many unread emails I have. After a bit of searching I found ot that there’s an atom feed that can be used to do exactly that, https://mail.google.com/mail/feed/atom. It uses basic authentication, your GMail username and password. So, I started looking at Python and HTTP.

urllib2 seemed to fit the bill. It has a class called HTTPBasicAuthHandler to do the authentication and everything. I used the following code (entered in ipython of course):

import urllib2
req = urllib2.Request('https://mail.google.com/mail/feed/atom')
try:
    h = urllib2.urlopen(req)
except IOError, e:
    pass
e.headers['www-authenticate']

It should produce something like 'BASIC realm="New mail feed"'. Now we can do the proper connection, pull down the atom entry. I opted to use elementtree since it’s so easy to use. Here’s the full code I put together for this little experiment:

import urllib2
from elementtree.ElementTree import fromstring

ah = urllib2.HTTPBasicAuthHandler()
ah.add_password('New mail feed', 'https://mail.google.com', \
    'user@gmail.com', 'password')
op = urllib2.build_opener(ah)
urllib2.install_opener(op)
res = urllib2.urlopen('https://mail.google.com/mail/feed/atom')

lines = ''.join(res.readlines())
e = fromstring(lines)
fc = e.find('{http://purl.org/atom/ns#}fullcount')
print 'You have %i unread mail(s) in your GMail account' % int(fc.text)

It just didn’t feel right to have KeySafe use a Windows-style INI file for its configuration so I started looking into using GConf instead.

There are good introductions to GConf here and here. Translating it all to Python is simple thanks to the brilliant people who gave us Gnome-Python.

I wrote this code for viewing the setting of the desktop background’s filename:

#! /usr/bin/python

import gtk
import gtk.glade
import gconf

class GConfViewer:
    def __init__(self):
        gui = gtk.glade.XML('Viewer/viewer.glade')
        self.entry = gui.get_widget('entry')

        client = gconf.client_get_default()
        client.add_dir('/desktop/gnome/background',
                gconf.CLIENT_PRELOAD_NONE)
        client.notify_add('/desktop/gnome/background/picture_filename',
                self.new_background)
        self.new_background(client)
        gui.get_widget('window').show_all()

    def new_background(self, client, *args, **kwargs):
        filename = client.get_string(
                '/desktop/gnome/background/picture_filename')
        self.entry.set_text(filename)

if __name__ == '__main__':
    GConfViewer()
    gtk.main()

I really like the client-server nature of it. A short explanation:

1. Get the default GConf client.
2. Add directories.
3. Tell it to watch a specific key, specifying a callback method to be called when its value is changed.
4. Define the callback method.

I also wrote code to change the value of a key:

#! /usr/bin/python

import gconf

def set_bool_key(key):
    client = gconf.client_get_default()
    client.set_bool(key, 1)

if __name__ == '__main__':
    set_bool_key('/desktop/gnome/background/draw_background')

Quite self-explanatory, isn’t it?

The next step in development would be to create a schema for the keys. Both introductions above contain pointers on how to write schemas, for more pointers just take a look in /usr/share/gconf/schemas/. The only problem I ran into was registering the schema. The following commandline does the trick:

GCONF_CONFIG_SOURCE=$(gconftool-2 --get-default-source) \
gconftool-2 --makefile-install-rule keysafe.schemas

Of course the kind Debian developers have done their best to shield packagers from nitty-gritty details. CDBS didn’t just work, it seems to make assumptions about the build system of the package (assuming it’s using auto-tools). Just making sure that the schema ends up in usr/share/gconf/schema during package binary-install, then call dh_gconf -ppackage in binary-post-install/package did the trick.

A few days ago I stumbled on this article by Mr. AkaImBatman. I posted a message on the Ubuntu developer’s list. A reply mentioned a rather long rant on the article. I couldn’t help but comment on it (under the name Magnus of course).

I am sure everyone has heard by now that the European politicians digged deep and managed to find some intelligence and common sense–the directive on “harmonisation of the patent rules”, which would allow software patents, was voted down. Legally we seem to be back where we began. FFII has managed to reach farther than what was thought possible and a lot of knowldege has been gained. FFII is now very well equipped to meet the next attempt by the patent cartel to introduce software patents.

A few days ago I didn’t hold much hope about the outcome of today’s vote and I wrote the following:

I’d like to express my thanks to the European politicians who have decided to finally introduce software patents in the EU. This means that European software developers have finally become men. No longer are we nerds and geeks sitting inside, slowly turning more and more gray in front of our screens. Thanks to the MEPs we have now become men. We are no longer second rate compared to our American cousins, but we have taken our rightful place next to them as real, manly software programmers. Manly? Yes of course! Thanks to our enlightened politicians software development has now become an extreme sport. It can be found right up there with sky diving and rock climbing in the list of dangerous passtimes. As a matter of fact software programming offers dangers on several levels, raising the bar for all extreme activities! For the first time there is a hobby that offers all of the following dangers:

• losing your livelyhood simply by realising one’s ideas and distributing the results
• several years of being dragged to court
• navigating a minefield of obvious ideas and solutions forcing the use of complex and error-prone algorithms

I’m sure all rock climbers are envious and are considering taking up programming by now.

Thank you European politicians!

/Magnus Therning

Luckily the world turned out to be a better place than I tought it was.

Webgoat is pretty cool! It’s a good idea, and to a large part it delivers what it promises. My main gripes:

• Some of the lessons listed are actually not available, they aren’t implemented yet. A bit disappointing to first see the long list and then being cheated out of about 5 of them.
• I didn’t get one of the lessons to complete, the one on dangerous XSS. I’m not sure but I think the reason was I’m not using a browser made by Microsoft.
• One lesson, the one with the admin interface, I didn’t finish. The hints were utterly useless (what source should I follow?). After looking both in the source in WebGoat and in WebGoat’s CVS repo (you don’t have to play fair when breaking things you know) I was even more confused.

Many lessons are somewhat simplistic and naive, I don’t doubt people still make those mistakes though. I’d say WebGoat is a nice, short, introduction to hands-on playing with web vulnerabilities.

The maybe most valuable thing about WebGoat is that it suggests using WebScarab.

I’ve finally found the time to check out OWASP‘s WebGoat. I have been putting this off for a while now, but it’s kept my interest enough to make me keep the zip-files on my desktop for a few weeks already.

My first impression wasn’t too good. I tried running it on Linux first (preferred platform for work/play/goofing around, yes anything) but installation failed miserably. The zip-file containing JDK1.5 only contains Java for Windows. Luckily I have Sun’s JDK1.5 on my Ubuntu machine already so I switched to using the StandAlone version. Now began the fun. There are numerous problems with the shell-scripts:

• they are not executable
• they have DOS line-endings
• the main setup script has a wacky reference to JAVA_HOME
• all files are read-only (not only the scripts, but all files)

So, after a call to ‘chmod’ to make everything writable, a few calls to dos2unix and chmod +x on the script files, a quick edit of webgoat.sh to set JAVA_HOME to something sane I thought I’d be off. Oh, no! Running webgoat.sh results in nothing. netstat -lpt reveals there is some java app listening on port 8005, but pointing my browser to it results in nothing. The total lack of documentation on how to use it didn’t help in my frustration.

After browsing the WebGoat Archives I turned off my Apache2 to free up port 80. Rerun webgost.sh, still nothing!

Some more browsing the archives revelead that I’m not only one having problems running WebGoat on Linux , the answer wasn’t too encouraging. I decided to try my luck on (yuck) Windows. Unzip, run the bat-file, point a browser to http://localhost/. Wow, worked perfectly!

Ok, on to the next problem, where are the lessons? Again, bitten by the lack of documentation it seems. Well, the archive has been saving me before… Again, I’m not the only one having problems the answer was there as well:

http://localhost/WebGoat/attack
Username: guest
Password: guest

Worked again, and now I can start taking the lessons. Not a great start, but after this bumpy ride I got to the destination. I do hope the WebGoat developers improve on the Linux support and documentation though!

I’ve just put up a page on AssureDate. It’ll be interesting to see if anyone thinks it’s a good idea or not. The thing is very low-tech at the moment. No automated handling of requests, not even a mandated format for requests, or for the issues AssureDate files for that matter. I’m very much planning to tackle issues as they arise, in the end this won’t make me any money at all.

Well, here goes nothing as they say…