It has some dependencies not yet in portage, so you need the gnome and the bangert overlay – for “easy” installation on Gentoo.

$ layman -a gnome
$ layman -a bangert
$ emerge -av entangle

Mind you, entangle-0.1.0 is its first release, but it works pretty well already. Daniel Berrangé – the principal developer behind entangle – has been very responsive in fixing a nasty segfault. Thanks.

The recent slew of webkit browsers then added Arora to the mix, which was a really nice experience. I use it a lot on Windows too. However, the reason I like Konqueror so much, is due to the really good Desktop integration – especially the wallet has me hooked. Granted, Firefox provides a similar experience, but its slow startup times and less slick KDE integration have always put me off.

Now, rekonq is an attempt to provide a Konqueror-like, but webkit based alternative. The ambition, so it seems, is to produce a browser that is compatible with Konqueror: Among other things it will use the passwords stored in the wallet by Konqueror. That makes for a nice transition between the two browsers.

Over the past few weeks, rekonq has first replaced Arora and now even Konqueror, which I have demoted as second in line for the text/html mime-type.

If you like Konqueror I urge you to try rekonq. Its available in portage as www-client/rekonq

$ sudo emerge -pv rekonq


Rekonq’s fast paced development can be followed over at http://gitorious.org/rekonq

In the meantime a number of tunnelling mechanisms have been developed, among them Teredo. Miredo is a GPL implementation of Teredo and it is now available in Portage.

The advantage of Toredo is, that it also works through NAT. Windows Vista and later have Teredo support built-in.

To enable Teredo on Gentoo, simply sync portage and emerge and start miredo:

$ sudo eix-sync
$ sudo emerge -av net-misc/miredo
$ sudo /etc/init.d/miredo start


To start miredo at boot, do

$ sudo rc-update add miredo default


Now go to http://www.kame.net/ and watch the turtle dance

Turns out that older devices where using a USB to serial converter to provide the USB interface: these show up as /dev/ttyUSBx – with x being an integer. The device I bought is a newer generation who appear to have an on-chip USB port, which will show up as /dev/ttyACMx (x again being an integer). So, support for ttyACMx type devices is needed in BT747. See bug #281888.

It turns out BT747, being a java app, uses rxtx to provide support for serial device communication. So lets fix rxtx – see bug #301126.

Meanwhile there is also mtkbabel in portage, which is not so picky about the device names.

Recently voting was enabled on the Gentoo bugzilla.

So go vote – yeah, also for the EP and the next queen, if you have the privilege.

So – you’ve always wanted to help out Gentoo? A common way to help is by providing a mirror – either distfiles or rsync. We have a good list of mirrors, both rsync and distfiles. Setting up a mirror is a huge commitment and my thanks go out to all those who do.

Due to the large requirements for diskspace, bandwith and cpu power, this is usually not an option for individuals.

However, Gentoo releases are also distributed using BitTorrent.

A good way to help gentoo is to

• use bittorrent to download releases.
• keep seeding after the download has finished.
• seed the other isos and stages as well.

There is a large number of bittorrent clients available for linux and many of them are available in portage. On my desktop I use ktorrent which works really well.

However, since my uplink to the internet is quite limited, it occurred to me, to run a bittorrent client on my Virtual Private Server (VPS).

Looking for an CLI bittorrent client I found rtorrent. Here is how to get started:

• Install rtorrent

  Most distributions have rtorrent packages – so does Gentoo

  $ emerge -av rtorrent

• Start screen

  You will want to have rtorrent running also when you disconnect from your VPS. screen allows you to do that.

  $ screen

• Configure rtorrent

  Here we disable up- and download throttling – YMMV.

  $ cat > ~/.rtorrent.rc
  download_rate = 0
  upload_rate = 0
  ^D

• Start rtorrent

  
$ rtorrent


• Download torrents

  Press backslashbackspace and paste a URL to a torrent from torrents.gentoo.org. Hit enter. Continue adding all the torrents you want to help with – the more the merrier.

• Wait

  rtorrent will now download the isos. At the same time it will start seeding. You can now detach from screen – press CTRL-a + d

• Watch

  Reconnect to your running rtorrent using screen:

  $ screen -r

  You will be able to see how much traffic you already have seeded. Press right to see details of the individual torrents.

• That’s it.

Click to enlarge.

In the past week the rtorrent on my VPS seeded roughly 13 GB. The VPS has a big pipe, so most likely this has speed up some peoples download of gentoo release isos and stages.

Warning: If your VPS plan does not have a lot of traffic included, you may want to keep an eye on the traffic counter. There is also the possibility of configuring upload throttling, which limits the amount of bandwith rtorrent will use.

Check out the rtorrent man page for a more detailed look on how to use and configure rtorrent.

Happy Seeding.

The purpose of the HTTPOnly flag is to prevent cross-site scripting (XSS) attacks. The idea is, that the browser will use the HTTPOnly-flagged cookie only when doing HTTP requests. It will not, as it normally would, make this cookie available to client side scripting languages (like JavaScript).

The HTTPOnly flag has been introduced by Microsoft as part of Service Pack 1 for Internet Explorer 6, released in September of 2002.

A neat idea, as limiting the possibilities for XSS vulnerabilities can only be good. However, being an extension to the standard, this requires support in both the server and the client. Microsoft did the first step, so how do the other involved parties hold up?

PHP added support for the HTTPOnly cookie in version 5.2, released in November of 2006.

Current releases of Firefox do not support HTTPOnly cookies. Version 3, however, will support HTTPOnly cookies. And Stefan Esser, of Hardened-PHP and suhosin fame, wrote an extension for Firefox 2.0 which supports HTTPOnly cookies.

Opera will support HTTPOnly cookies in version 9.5.

I am not sure whether KHTML or WebKit support HTTPOnly cookies.

Apparently ancient browsers break when asked to process a HTTPOnly cookie. In this day and age this should not be too big a problem however.

It appears, that Microsoft, as unlikely as it may seem, had a pretty decent idea, but the open source community did not respond as one could have hoped.
Is this NIH?

Now, after the LiveJournal incident, which could have been prevented if HTTPOnly cookies were widely supported, an increased effort seems underway to finally get this implemented.

Of course, HTTPOnly cookies do not protect against all types of XSS attacks. Nevertheless, it is another layer of protection for which I am grateful. I was surprised to learn that this was introduced by Microsoft AND that the open source community hasn’t adopted this feature more widely. Microsofts positive impacts on this industry do exist afterall…

Getting there was a bit tricky, as nistp224 (ebuild) — an elliptic curve crypto library — did not compile using gcc-4. Luckily Griffon26 is more asm-savy than I am and within minutes he produced a working patch. (Thanks!)

Anyway – getting srlog2 to work is a breeze:

1. On the receiver aka. central loghost, create srlog2d keys

   
receiver.example.com $ srlog2-keygen -t nistp224 /var/log/srlog2

   The public key will need to be distributed to all sending hosts (see step 5).

2. Set the private key as server key

   
receiver.example.com $ mv /var/log/srlog2/nistp224 /var/log/srlog2/secrets


3. Use the following run file to start srlog2d

   
#!/bin/bash
cd /var/log/srlog2
exec srlog2d srlog2-logger --mkdirs


4. On the sender, create host keys

   
sender-hostname.example.com $ srlog2-keygen -t nistp224 /etc/srlog2

   The public key needs to be put on the receiving host (see step 7).

5. Put the receivers public key into /etc/srlog2/servers/receiver.example.com.nistp224
6. Start a log service. srlog2 takes a log line from standard input and sends it to the central loghost. It is designed to be similar to multilog and thus also supports the patterns.

   
sender-hostname.example.com $ srlog2 bla receiver.example.com
--type stuff--


7. Before the above will work you need to put the senders public key into /var/log/srlog2/senders. Prepend it with its hostname (not fqdn) followed by a semicolon:

   
sender-hostname:nistp224:0kfFexdXjzVPPRQOUbLq3f2K9fDqC2BDsE3o/Q==


Done!

You will now start to see logfiles in /var/log/srlog2/sender-hostname/bla/. If everything worked well, you should be seeing what you typed in step 6.

If you want to use curve25519 instead of nistp224, replace all occurrences of nistp224 above accordingly. However, currently curve25519 is only supported on 32-bit x86.

Note: The example above is only meant to get you up and running. On a production system the server keys would not be stored in /var/log/srlog2. Also be aware of funny line wrapping in the shell commands above.

Update: it was pointed out to me, that dragonheart already had prepared ebuilds for nistp224 and srlog2. And they are much more refined too. Way cool!

Happy hacking!

The company I work for develops learning tools using flash and flex2. For this reason I tried to create an ebuild for mod_flex – an apache module which compiles adobe flex code (.mxml) on the fly… which is great, as you get a .swf back and thus it is much easier to test things during development. Adobe originally provided an installer for the apache module – a horrible idea, as the installer required java and a X terminal and was generally broken (for me). Upon (not only) my complaint, Adobe now distributes a plain old zip file and thus a mod_flex ebuild is a reality. Installer programs are so 1990ies..

enhost – a program which adds system facts (collected using facter from the same author) into a ldap database – is not in the tree (yet) but I’ve added it to my overlay. Great concept – although enhost could need some love. I am currently investigating server inventory systems for which enhost (or a similar program) could be pretty helpful. This morning I found nVentory which looks promising.

Both facter, enhost and nVentory are written in Ruby. nVentory is web-based and thus uses Rails. In an effort to try to grasp this language I have created some scripts which check the metadata of the portage tree. In turn this resulted in a spree of herd fixing… Thus far I enjoy Ruby and I would not mind doing more with it.

With exams out of the door – I plan on being more present in the community (IRC – uhu)… lets see how that works out.

He is going to talk about The Danger of Software Patents, a topic covered by him on numerous occasions already. Nevertheless I am planning on being there – give me a shout and we can meet up.

… I really need a Gentoo (t-)shirt…

Fighting patents one by one will never eliminate the danger of software patents, any more than swatting mosquitoes will eliminate malaria.

Richard Stallman