On Saturday evening I started talking with M nica about Bug Squashing Parties and how they work. I am not sure how it happened, we started doing one. Then it was too fun to stop :P NMUs by M nica:

• t1lib #646470 This one had a patch by Colin Watson and Lo c Minier
• torcs: #646469 and 636009
• slsqlite: #646487
• webdruid: #646499
• vilistextum: #646501

Funny, there were a couple of NMUs by others uploading patchs by M nica. NMUs by Ana:

• uw-imap: #646481 This one had a patch by Aur lien Jarno.
• remind: #643466
• sipcalc: #646502
• libcsoap: #643420
• tuxpaint: #556509 With patch by Georgios M. Zarkadas.

I also closed #646449 (libosip2) that has been fixed in a new release upload, sponsored a NMU to Sven Joachim who had a patch sitting in the BTS for a month NMU-fixing #646147 (lie), sponsored dbus-c++ and reviewed for sponsoring a new version inspircd.

At work we use .procmailrc files generated by CGIpaf to let non-technical users create forwards, out-of-office mails, etc. and any combination thereof. This also has the advantage that we can filter out double bounces and spam (which also prevents us from being listed in spammer blacklists). Unfortunately autofs (seems independent if autofs4 or autofs5 is used) seems to be unreliable if there are bursts of mount or umount requests, resulting either in File or directory not found error message while trying to access the home directory of a user, or Directory not empty error messages if the automounter tries to remove the mount point after unmounting. In that case a not mounted directory owned by root is left over. In the end both cases lead to procmail behaving as if that user does not have a .procmailrc which looks like sporadically lost mails to those who forward all mails. (The mails then can be found in the local default INBOX for that user.) Additionally there are similar issues when the NFS servers are not available. The most effective countermeasure we found so far was adding tests to the global /etc/procmailrc to check if the user s home directory exists and belongs to the correct user:

# -----------------
# Global procmailrc
# -----------------
# For debugging, turn off if everything works well
VERBOSE=1
LOGFILE=/var/log/procmail.log
# This only works with bourne shells, $SHELL defaults to the user's
# login shell. And by experience dash seems not work, so we use bash.
OLDSHELL=$SHELL
SHELL=/bin/bash
# temporary failure (see EX_TEMPFAIL in /usr/include/sysexits.h) if
# $LOGNAME is not set for some reason. (Just to be sure our paths
# later on are not senseless.
:0
* ? test -z "$LOGNAME"
 
    LOG="Expected variable LOGNAME not set. "
    EXITCODE=75
    :0
    /dev/null
 
# temporary failure (see EX_TEMPFAIL in /usr/include/sysexits.h) if
# $HOME is not readable. ~$LOGNAME does not seem to work, so this uses
# a hard wired /home/.
:0
* ? test ! -r /home/$LOGNAME
 
    LOG="Home of user $LOGNAME not readable: /home/$LOGNAME "
    EXITCODE=75
    :0
    /dev/null
 
# temporary failure (see EX_TEMPFAIL in /usr/include/sysexits.h) if
# $HOME has wrong owner. ~$LOGNAME does not seem to work, so this uses
# a hard wired /home/.
:0
* ? test ! -O /home/$LOGNAME
 
    LOG="Home of user $LOGNAME has wrong owner: /home/$LOGNAME "
    EXITCODE=75
    :0
    /dev/null
 
[ ]

If you want to store a copy of these mails for debugging purposes on every delivery attempt, replace /dev/null with some Maildir or mbox only accessible for root. One small but important part was to explicitly declare bash as shell for executing the tests, otherwise mails for users with tcsh or zsh as login shell filled up the mail queue and never get delivered (if the SHELL variable never gets fixed). Only drawback so far: This leads to more lagging e-mail on e-mail bursts also for those users who have no .procmailrc because procmail can t check if there s really no .procmailrc. Extensive procmail documentation can be found online at the Procmail Documentation Project as well as in the man pages procmail(1), procmailrc(5) and procmailex(5).

Uff. Two and a half days of hunting release critical bugs ended yesterday evening. It think it was quite a success. According to the statistics we closed 23 bugs with direct uploads, we created patches for 11, 9 bugs got solved by package removals, 6 will be closed by uploads via the delayed queue, 2 bugs were closed as unreproducible, and 9 other bugs where closed as well (e.g. already fixed in older version). On the other hand we opened 3 and upgraded 6 bugs to be release critical. So in the end, we solved about... 60 bugs! Wow, I'm really impressed! I'm also really pleased how well we integrated the newbs. As I already mentioned, when planing for this BSP started, we were a bit worried about the DD / non-dd ratio, but in the end everything worked out very well. All of those, who registered as interested users where able to fix some rc bugs, or help sort out some BTS hickups, e.g. bugs opened with package a but closed in package b. And as a special pleasure it seems, that the longest outstanding rc bug might be fixed soonish, too :) I'd also like to thank Pengutronix for hosting and sponsoring the BSP! The infrastructure worked very well: You arrived, plugged in your notebook, had a local mirror, IPv6 and fast enough connection to the outside. They also provided lots of snacks, cooked food and drinks (later they complained Debian people won't drink enough; apparently they calculated with way more drinks) and a general good atmosphere. PS: To the best of my knowledge, it was also the greenest bug squashing party ever, with most foods and all the electricity coming from certified ecological production. Cool, eh?

here's my report about RC bug related activities for the last week. besides working on the bugs mentioned below I've also documented my RCBW work flow for the NMUs, just in case it's interesting for others.

• #615705 dasher: "dasher: ftbfs with gold or ld --no-add-needed"
  add patch from M nica Ram rez Arceda, upload to DELAYED/2
• #628590 siggen: "please make siggen depends on oss-compat"
  add missing dependency, do a QA upload
• #633453 drac: "drac: fails to install due to incorrect dependencies in init.d LSB header"
  add patch from Ubuntu / Daniel T Chen, upload to DELAYED/2
• #634451 src:hwinfo: "hwinfo: FTBFS: /usr/include/dbus-1.0/dbus/dbus.h:29:33: fatal error: dbus/dbus-arch-deps.h: No such file or directory"
  add patch from Simon McVittie, upload to DELAYED/2
• #638379 xine-ui: "xine-ui: fatal error: curl/types.h: No such file or directory"
  add patch from Ubuntu / Daniel T Chen, upload to DELAYED/2
• #639772 src:slrn: "slrn: FTBFS: checking for the slang library and header files ... no"
  point configure to multiarched slang, upload to DELAYED/2
• #639991 guile-1.8-non-dfsg: "guile-1.8-non-dfsg fails to build from source in unstable"
  add patch from Ubuntu / Matthias Klose, upload to DELAYED/2
• #640439 src:gtk-nodoka-engine: "gtk-nodoka-engine: FTBFS: nodoka_style.c:1279: undefined reference to sqrt'"
  add patch from Ubuntu / Micah Gersten, upload to DELAYED/2
• #640883 libnet-ldap-perl: "regression: breaks $ldap->start_tls()"
  add patch from Peter Marschall, taken from upstream's "next" branch (pkg-perl)
• #643339 src:most: "most: build fails on configure-step (couldn't find slang.h)"
  add patch from Ubuntu / Daniel T Chen, upload to DELAYED/2
• #643371 src:dasher: "dasher: FTBFS: game_mode_helper.cpp:327:15: error: format not a string literal and no format arguments [-Werror=format-security]"
  add patch from Eric Alexander, upload the DELAYED/2
• #649066 libmason-perl: "libmason-perl and mason: error when trying to install together"
  upload new upstream release, package prepared by Florian Schlichting (pkg-perl)

I have written about using lossless optimisations techniques to reduce the size of images before, but I recently learned of a few other tools to further reduce the size of PNG images.

Basic optimisationWhile you could use Smush.it to manually optimise your images, if you want a single Open Source tool you can use in your scripts, optipng is the most effective one:

optipng -o9 image.png

Removing unnecessary chunksWhile not as effective as optipng in its basic optimisation mode, pngcrush can be used remove unnecessary chunks from PNG files:

pngcrush -q -rem gAMA -rem alla -rem text image.png image.crushed.png

Depending on the software used to produce the original PNG file, this can yield significant savings so I usually start with this.

Reducing the colour paletteWhen optimising images uploaded by users, it's not possible to know whether or not the palette size can be reduced without too much quality degradation. On the other hand, if you are optimising your own images, it might be worth trying this lossy optimisation technique.

For example, this image went from 7.2 kB to 5.2 kB after running it through pngnq:

pngnq -f -n 32 -s 3 image.png

Re-compressing final imageMost PNG writers use zlib to compress the final output but it turns out that there are better algorithms to do this.

Using AdvanceCOMP I was able to bring the same image as above from 5.1kB to 4.6kB:

advpng -z -4 image.png

When the source image is an SVGAnother thing I noticed while optimising PNG files is that rendering a PNG of the right size straight from an SVG file produces a smaller result than exporting a large PNG from that same SVG and then resizing the PNG to smaller sizes.

Here's how you can use Inkscape to generate an 80x80 PNG:

inkscape --without-gui --export-width=80 --export-height=80 --export-png=80.png image.svg

Four years ago, during DebConf 7 in Edinburgh, I had the idea of creating init scripts not by hand, but rather describe them in a declarative way that handles most common cases and generate the real init scripts from them. Back than, this was partly motivated by the varying quality of init scripts and the advent of an alternative init system, upstart, for which proper service files could be generated as well. I implemented the idea and uploaded it as metainit to Debian, but it did not take off. Only one package uses it, and this package is not used much either. The project basically fell dormant. Yesterday, I got this mail:

Hi Joachim, I'm not very familiar with Debian ecosystem, however our company has recently switched to exclusively using Debian based servers, please forgive me if there exists a better channel for sending patches. We need (in house) to create a lot of trivial services and the sysv init system seems an ideal way to manage them, and metainit an great way to keep the config simple. However all our scripts require a heartbeat, the way we normally do this is with a bunch of checkers launched from cron. Metainit was ideal, but lacked the simple 'status' task found in most init scripts. This small patch adds that task, I hope you and others find it usefull. Regards,

together with the mentioned patch. So it turned out that the idea was a useful one after all, although it found its use on our user s machines, and not within the Debian packages, as I originally anticipated. Nice! During the recent discussions about the latest init system, systemd, there were more thoughts about generating init scripts/upstart service descriptions/systemd units from a declarative description, and if metainit had taken off back then, things would be easier now. So if anyone feels like reviving the project: Please do.

Flattr this post

We have customers, which require a report about what we've done during maintenance windows. Usually this includes a report about upgrades, newly installed packages etc. and obviously everything we've done apart from that.
Till now we've prepared them manually. For a greater bunch of systems this is a big PITA, because to be somehow useful you have to collect the data for all systems and after that, prepare a report where you have:

• The upgrades done on all systems (e.g. a libc or kernel update)
  
  seperated from
  
• the updates specific to a certain system or system class

Its also error-prone because humans make mistakes.

Perl to the rescue!
At least the part about generating a report about installed/upgraded/removed packages could be automated, because dpkg writes a well-formed logfile in /var/log/dpkg.log. But I noticed that there appearently is no library specialised at parsing that file. Its not a big deal, because the format of that file is really simple, but a proper library would be nice anyway.
And so I wrote such a library.
It basically takes a logfile, reads it line by line and stores each line parameterized into a generic object.

Its features include:

• Parsing the logfile (obviously)
• Storing each line in a logfile as a DPKG::Log::Entry object that holds informations about the entry type (e.g. action or status update), the package associated (if any), timestamp, verbatim line, line number etc.

• Limiting the number of lines parsed to a time range specified by DateTime objects

Based on that, I wrote another library DPKG::Log::Analyse, which takes a log, parses it with DPKG::Log and then extracts the more relevant information such as installed packages, upgraded packages, removed packages etc.

This, in turn, features:
- Info about newly installed packages
- Info about removed packages
- Info about upgraded packages
- Info about packages which got installed and removed again
- Info about packages which stayed halfinstalled or halfconfigured at the end of the logfile (or defined reporting period)


These libraries are already uploaded to CPAN and packaged for Debian.
They passed the NEW queue very quickly and are therefore available for Sid:

http://packages.debian.org/sid/libdpkg-log-perl

As an example use (and for my own use case, as stated above), I wrote dpkg-report, which uses the module and a Template::Toolkit based template to generate a report about what happened in the given logfile.
It currently misses some documentation, but it works somehow like this:

Report for a single host over the full log:

dpkg-report

Report for a single host for the last two days:

dpkg-report --last-two-days

Report for multiple hosts (and logfiles):
The script expects that each log file has the name <systemname>.dpkg.log so that it can guess the hostname from the system and can grab all such log files from a directory if a directory is specified as log-file arguments:</systemname>

dpkg-report --log-file /path/to/logs

This will generate a report about all systems without any merging.

Report for multiple hosts with merging:

dpkg-report --log-file /path/to/logs --merge

This will do the following:

• Report packages which where installed/removed/etc. on all systems seperate from the upgrades only done on the specific systems
• If systems start with a common name and end on a number (e.g. mail1, mail2, mail3 etc.), report packages which where installed on all systems with that common name seperate from the upgrades only done on the specific systems
• For a specific system list only the changes on that particular system and nothing else.

A (fictive) report could look some what like this:

dpkg-Report for all:
------------------------
Newly Installed:
abc
Removed:
foo
Upgraded:
bar (0.99-12 - 1.00-1)
dpkg-Report for test*:
------------------------
Newly Installed:
blub
dpkg-Report for test1:
------------------------
Upgraded:
baz (1.0.0-1 -> 1.0.0-2)
dpkg-Report for test2:
------------------------
Upgraded:
zab (0.9.7 -> 0.9.8)

Currently this report generator is only included in the source package or in the git(hub) repository of the library. I wonder if it makes sense to let the source package build another binary package for it.
But its only a 238 lines perl script with a dependency on the perl library so I'm unsure if it warrants a new binary package. What do others think?

Yesterday the Bug Squashing Party in Hildesheim, Germany started. I think it's going well, according to the statistics of the #debian-bugs channel, we solved 11 bugs with direct uploads, 2 with uploads to delayed, 5 via package removals and opened/upgraded only one. So we are still fixing more than we break ;) I'm especially pleased that some of the above was done by newbies. When we started to organise this BSP (well, when I started to watch Meike and Wolfram organise it to be precise), we where kind of worried by the experienced developer to newbie ratio, and already started to prepare introductions to packaging and similar adhoc sessions, but as it seems they don't seem to be needed. Good :) So back to fixing stuff, good hunt!

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (310.73 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg: Multi-Arch Saga I know lots of people are waiting the landing of multiarch in Debian unstable, and so am I. Things are progressing, though not as quickly as I hoped. Guillem merged about half of the branch between the 24th October and the 6th of November. After that most of the work happened on his personal repository in his pu/multiarch/master branch. I verify this repository from time to time because Guillem does not inform me when he has made progress. I noticed changes on his repository on the 10th, 19th, 23th, 28th of November and on the 1th of December. He announced a long time ago that he had some interface changes and up to now only wrote about the switch from the command-line option --foreign-architecture (to put in /etc/dpkg/dpkg.cfg) to the explicit command dpkg --add-architecture that only needs to be called once (see mail here). As of today (December 2th), the promised email for the other interface changes is still not here. On November 23th, I reviewed Guillem s work and tried to run the code in his branch. I spent the whole day chasing up regressions and submitted lots of fixes to Guillem. Thanks to the extensive test-suite I wrote when I developed my branch, it has been fairly easy to track them all down. All the issues I reported have been fixed in the latest version of Guillem s branch although the fixes are often slightly different from those that I submitted. Dpkg: Squeeze Backport At the start of the month, I uploaded what I expected to be a fairly uncontroversial backport of dpkg 1.16.1.1. It turns out I was wrong. After some discussion, I think we came to an agreement that it was acceptable to backport dpkg-dev and libdpkg-perl only. My goal was not to bring the latest dpkg to users but to make it easier for package maintainers to backport packages using new features provided by dpkg-dev >= 1.16 (such as hardening build flags, the makefile snippets provided in /usr/share/dpkg/, or the improved dpkg-buildflags interface). Thus I modified the source package uploaded to squeeze-backports to build only dpkg-dev and libdpkg-perl. It has been uploaded on November 23th and it s waiting in the NEW queue for a backports admin to process it. Misc Dpkg Work I merged a patch of Colin Watson to be able to verify build-dependencies for a foreign architecture (taking into account the Multi-Arch status of each package listed). I released dpkg 1.16.1.2 with two minor fixes that were sitting in the sid branch. I wanted to get rid of this so that the path is clear for a 1.16.2 upload with multiarch. The package just migrated to testing so we re fine. I spent another day doing dpkg bug triaging on Launchpad, we re now down to 77 bugs with many of them tagged as incomplete and likely to expire in 2 months. The Debian Administrator s Handbook We released a sample chapter so that it s easier to have an idea of the quality of the book. The chapter covers the APT tools quite extensively. I bet that even you could learn something about apt-get/aptitude The crowfunding campaign on Ulule ended on November 28th.
With 675 supporters, we raised 24385 EUR. Of those, 14935 EUR have been put in the liberation fund and the rest corresponds to the various pre-orders and rewards offered. This means that the translation will happen (we just started) but that the book is currently not going to be released under a free license. Don t despair As planned, the liberation campaign is carried on until the 25 K target is reached! Instead of being hosted on Ulule, this permanent campaign is on the project website at debian-handbook.info/liberation/. Note that any contribution of 10 EUR or more means that you get a copy of the ebook as soon as it s available (even if the liberation target is not reached). Package Tracking System At the start of the month, I filed two ideas of improvements for the PTS in the bug tracking system: #647258 is about showing outstanding bugs that relate to a release goal and #647901 is about warning maintainers that the package is affected by a current transition. If you re a coder and want to start contributing to Debian and its QA team, those bugs could be interesting targets for a start. In both cases, I have been in contact with members of the release team because those ideas require some structured data from the release team as input. Thanks to Meddi Dohguy and Niels Thykier for their help. Later in the month, the topic of relocating the PTS once again came up. For historical reasons, the PTS was hosted on master.debian.org together with the BTS. Nowadays the BTS has its own host and it made no sense anymore to have the PTS separate from the rest of the QA services hosted on qa.debian.org (currently quantz.debian.org). So together with Martin Zobel Helas we took care to plan the migration and on November 19th we executed the plan. It worked like a charm and almost nobody noticed (only one undocumented dependency was missed, which broke the SOAP interface). Misc Packaging Work WordPress was broken in Ubuntu and it was also not properly synchronized with Debian due to an almost useless change on their side. Thus I requested a sync so that the working version from Debian gets imported in Ubuntu. I sponsored the docbook-xsl 1.76.1 upload that I needed for Publican. Then I updated Publican just to discover that the test-suite triggers a new bug in fop (filed as #649476). I disabled the test-suite temporarily and uploaded Publican 2.8 to unstable. BTW, I also filed 2 upstream bugs with patches for issues I discovered while trying to generate the sample chapter of my book (see here and here). I uploaded a version 0.7.1 of nautilus-dropbox and fixed #648215 at the same time. I made an NMU of bison to fix a long-standing release critical bug that hit me once more during an upgrade (see #645038). I uploaded to experimental a new version of gnome-shell-timer compatible with GNOME 3.2. I took the opportunity to install from experimental the few GNOME 3.2 packages which are not yet in unstable Thanks See you next month for a new summary of my activities.

7 comments Liked this article? Click here. My blog is Flattr-enabled.

Forbes has an interesting article about crowd-sourcing by criminals and law enforcement [1]. Ulissescastr0 made a Youtube video showing how to install SE Linux on Debian/Etch [2]. Probably no-one is using Etch nowadays so this video is outdated, but it s a good way of teaching people. It would be good if someone made a similar video showing how to do SE Linux things on Squeeze. I discovered the above SE Linux video through Explow which provides a neat interface to multiple searches and information sources [3]. I don t think I will be using Explow much in future as I could get the same result through Google video search. They also have a news portal but there are other sites for that. But it does seem that Explow would be useful for newbies. Eric Michael Johnson wrote an interesting article about the inherent bias in Psychological research based in the US [4]. People who live in urban environments think differently in some ways to people who live in different environments or who have different lifestyles. Therefore generalising from university students in the US to the entire human race is likely to get incorrect results. This is something to consider the next time you are tempted to generalise to the wider population from your own friends, colleagues, etc. The Daily Kos has a scary article about the TSA having a woman detained for reciting part of the US constitution [5]. The US will remain on my list of countries to avoid for the forseeable future. Vorlon has written an informative article about the use of hardening options when building Debian packages [6]. It s now even easier to do this, so every package that simultaneously deals with data of differing levels of integrity or sensitivity should be built this way. Bunker Roy gave an interesting TED talk about his Barefoot College that teaches useful skills to people in rural parts of India who don t have a traditional school education [7]. His talk really shows up some of the arrogance in the people who run traditional education. Justin Hall-Tipping gave an interesting TED talk about ways of solving the world energy problems [8]. He started with explaining the problems and why they need to be urgently solved and then described in detail some of the research that his group has done to solve the problems. This includes flexible photo-voltaic cells, infra-red vision to save on lighting, and a way of using carbon nano-tubes to control the thermal properties of windows.

• [1] http://www.forbes.com/sites/oreillymedia/2011/10/03/the-rise-of-crime-sourcing/
• [2] http://www.youtube.com/watch?v=FLPx7HLLteI
• [3] http://explow.com
• [4] http://blogs.plos.org/blog/2010/09/23/reflections-on-the-weird-evolution-of-human-psychology/
• [5] http://www.dailykos.com/story/2011/10/18/1027775/-TSA-Arrests-Me-for-Using-the-Fourth-Amendment-as-a-Weapon-(Tales-from-the-Edge-of-a-Revolution-2)?via=siderec
• [6] http://web.dodds.net/~vorlon/wiki/blog/Debian:_not_stale_just_hardened/
• [7] http://www.ted.com/talks/bunker_roy.html
• [8] http://www.ted.com/talks/justin_hall_tipping_freeing_energy_from_the_grid.html

If you want to copy debian-installer for System z onto a z/VM user's CMS disk, you don't need access to FTP (and hence the host's TCP/IP stack). You can just use x3270 and transfer files with it. For odd reasons I forgot about this, so let's document it here:

• Figure out which CMS disk is actually writeable for you (most likely the A disk) by issuing Q DISK and looking for "R/W" in the STAT column.
• Select File, File Transfer.
• Tick "Send to host" and "Host is VM/CMS".
• Download the four installer files to your local machine: debian.exec (a startup script that punches the kernel, boot parameters and initrd onto cards and executes the card deck), kernel.debian, parmfile.debian (the boot parameters) and initrd.debian.
• Transfer debian.exec and parmfile.debian with "Transfer ASCII file" ticked and Record Format set to "Variable" ("Add/remove CR at end of line" and "Remap ASCII characters" should both be ticked by default; LRECL and BLKSIZE should both be empty.) The host filename is the CMS filename, so something like "DEBIAN EXEC A" (with the spaces, and A replaces with the letter of the writeable disk of your choice). Both files must be prefectly readable in XEDIT (i.e. properly converted to EBCDIC).
• Then transfer kernel.debian and initrd.debian with "Transfer binary file" ticked and Record Format set to "Fixed" with LRECL = 80. This may take a while.
• Boot up the installer by issuing DEBIAN to z/VM, starting the script. If you needed to rename the files above (the drive letter doesn't matter), you need to adjust DEBIAN EXEC first.
• You should see Linux kernel messages now. Profit.

pbuilder release process for this month. I've started the cycle. There are several patches, I'm just going to integrate them and see how things go.

Once the private key of some HTTPS web site is compromised, an attacker is able to build a man-in-the-middle attack to intercept and decrypt any communication with the web site. The first step against such an attack is the revocation of the associated certificate through a CRL or a protocol like OCSP. Unfortunately, the attacker could also have recorded past communications protected by this private key and therefore decrypt them. Forward secrecy allows today information to be kept secret even if the private key is compromised in the future. Achieving this property is usually costly and therefore, most web servers do not enable it on purpose. Google recently announced support of forward secrecy on their HTTPS sites. Adam Langley wrote a post with more details on what was achieved to increase efficiency of such a mechanism: with a few fellow people, he wrote an efficient implementation of some elliptic curve cryptography for OpenSSL.

Without forward secrecy To understand the problem when forward secrecy is absent, let s look at the classic TLS handshake when using a cipher suite like AES128-SHA. During this handshake, the server will present its certificate and both the client and the server will agree on a master secret. This secret is built from a 48byte premaster secret generated and encrypted by the client with the public key of the server. It is then sent in a Client Key Exchange message to the server during the third step of the TLS handshake. The master secret is derived from this premaster secret and random values sent in clear-text with Client Hello and Server Hello messages. This scheme is secure as long as only the server is able to decrypt the premaster secret (with its private key) sent by the client. Let s suppose that an attacker records all exchanges between the server and clients during a year. Two years later, the server is decommissioned and sent for recycling. The attacker is able to recover the hard drive with the private key. She can now decrypt any session she recorded: the encrypted premaster secret sent by a client is decrypted with the private key and the master secret is derived from it. The attacker can now recover passwords and other sensitive information that can still be valuable today. The main problem lies in the fact that the private key is used for two purposes: authentication of the server and encryption of a shared secret. Authentication only matters while the communication is established, but encryption is expected to last for years.

Diffie-Hellman with discrete logarithm One way to solve the problem is to keep using the private key for authentication but uses an independent mechanism to agree on a shared secret. Hopefully, there exists a well-known protocol for this: the Diffie-Hellman key exchange. It is a method of exchanging keys without any prior knowledge. Here is how it works in TLS:

1. The server needs to generate once (for example, with openssl dhparam command):
   • p , a large prime number,
   • g , a primitive root modulo p (for every integer a coprime to p , there exists an integer k such that g^k=a\mod p ).
2. The server picks a random integer a and compute g^a \mod p . After sending its regular Certificate message, it will also send a Server Key Exchange message (not included in the handshake depicted above) containing, unencrypted but signed with its private key for authentication purpose:
   • random value from the Client Hello message,
   • random value from the Server Hello message,
   • p , g ,
   • g^a\mod p=A .
3. The client checks that the signature is correct. It also picks a random integer b and sends g^b \mod p=B in a Client Key Exchange message. It will also compute A^b\mod p=g^ ab \mod p which is the premaster secret from which the master secret is derived.
4. The server will receive B and compute B^a\mod p=g^ ab \mod p which is the same premaster secret known by the client.

Again, the private key is only used for authentication purpose. An eavesdropper will only know p , g , g^a\mod p and g^b\mod p . Computing g^ ab \mod p from those values is the discrete logarithm problem for which there is no known efficient solution. Because the Diffie-Hellman exchange described above always uses new random values a and b , it is called Ephemeral Diffie-Hellman (EDH or DHE). Cipher suites like DHE-RSA-AES128-SHA use this protocol to achieve perfect forward secrecy¹. To achieve a good level of security, parameters of the same size as the key are usually used (the security provided by the discrete logarithm problem is about the same as the security provided by factorisation of two large prime numbers) and therefore, the exponentiation operations are pretty slow as we can see in the benchmark below:

Diffie-Hellman with elliptic curves Fortunately, there exists another way to achieve a Diffie-Hellman key exchange with the help of elliptic curve cryptography which is based on the algebraic structure of elliptic curves over finite fields. To get some background on this, be sure to check first Wikipedia article on elliptic curves. Elliptic curve cryptography allows one to achieve the same level of security than RSA with smaller keys. For example, a 224bit elliptic curve is believed to be as secure as a 2048bit RSA key.

Some theory Diffie-Hellman key exchange described above can easily be translated to elliptic curves. Instead of defining p and g , you get some elliptic curve, y^2=x^3+\alpha x+\beta , a prime p and a base point G . All those parameters are public. In fact, while they can be generated by the server, this is a difficult operation and they are usually chosen among a set of published ones. The use of elliptic curves is an extension of TLS described in RFC 4492. Unlike with the classic Diffie-Hellman key exchange, the client and the server need to agree on the various paremeters. Most of this agreement is done inside Client Hello and Server Hello messages. While it is possible to define some arbitrary parameters, web browsers will only support a handful of predefined curves, usually NIST P-256, P-384 and P-521. From here, the key exchange with elliptic curves is pretty similar to the classic Diffie-Hellman one:

1. The server picks a random integer a and compute aG which will be sent, unencrypted but signed with its private key for authentication purpose, in a Server Key Exchange message.
2. The client checks that the signature is correct. It also picks a random integer b and sends bG in a Client Key Exchange message. It will also compute b\cdot aG=abG which is the premaster secret from which the master secret is derived.
3. The server will receive bG and compute a\cdot bG=abG which is the same premaster secret known by the client.

An eavesdropper will only see aG and bG and won t be able to compute efficiently abG . Using ECDHE-RSA-AES128-SHA cipher suite (with P-256 for example) is already a huge speed improvement over DHE-RSA-AES128-SHA thanks to the reduced size of the various parameters involved. Web browsers only support a handful of well-defined elliptic curves, chosen to ease an efficient implementation. Bodo M ller, Emilia K sper and Adam Langley have provided 64bit optimized versions of NIST P-224, P-256 and P-521 for OpenSSL. To get even more details on the matter, you can read the end of the introduction on elliptic curves from Adam Langley, then a short paper from Emilia K sper which presents a 64bit optimized implementation of the NIST elliptic curve NIST P-224.

In practice First, keep in mind that elliptic curve cryptography is not supported by all browsers. Recent versions of Firefox and Chrome should handle NIST P-256, P-384 and P-521 but for most versions Internet Explorer, you are currently out of luck. Therefore, you need to keep accepting other cipher suites. You need a recent version of OpenSSL. Support for ECDHE cipher suites has been added in OpenSSL 1.0.0. Check with openssl ciphers ECDH that your version supports them. If you want to use the 64bit optimized version, you need to run a snapshot of OpenSSL 1.0.1, configured with enable-ec_nistp_64_gcc_128 option. A recent GCC is also required in this case. Next, you need to choose the appropriate cipher suites. If forward secrecy is an option for you, you can opt for ECDHE-RSA-AES128-SHA:AES128-SHA:RC4-SHA cipher suites which should be compatible with most browsers. If you really need forward secrecy, you may opt for ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:EDH-DSS-DES-CBC3-SHA instead. Then, you need to ensure the order of cipher suites is respected. On nginx, this is done with ssl_prefer_server_ciphers on. On Apache, this is SSLHonorCipherOrder on. UPDATED: You need to check ECDHE support for your web server. For nginx, the support has been added in 1.0.6 and 1.1.0. The curve selected defaults to NIST P-256. You can specify another one with ssl_ecdh_curve directive. For Apache, it has been added in 2.3.3 and does not exist in the current stable branch. Adding support for ECDHE is quite easy. You can check how I added it in stud. This issue also exists for DHE cipher suites, in which case you also might have to specify DH parameters to use (generated with openssl dhparam) using some special directive or by appending the parameters to the certificate. Check Immerda Techblog article for more background about this point. The implementation of TLS session tickets may be incompatible with forward secrecy, depending on how they are implemented. When they are protected by a random key generated at the start of the server, the same key could be used for months. Some implementations² may derive the key from the private key. In this case, forward secrecy is broken. If forward secrecy is a requirement for you, you need to either disable tickets or ensure that key rotation happens often. Check with openssl s_client -tls1 -cipher ECDH -connect 127.0.0.1:443 that everything works as expected.

Some benchmarks With the help of the micro-benchmark tool that I developed for my previous article, we can compare the efficiency of cipher suites providing forward secrecy: I have used a snapshot of OpenSSL 1.0.1 (2011/11/25). The optimized version of ECDHE is the one you get by using enable-ec_nistp_64_gcc_128 option when configuring OpenSSL. Let s focus on the server part. Enabling DHE-RSA-AES128-SHA cipher suite hinders the performance of TLS handshakes by a factor of 3. Using ECDHE-RSA-AES128-SHA instead only adds an overhead of 27%. However, if we use the 64bit optimized version, the cost is only 15%. The overhead is only per full TLS handshake. If 3 out of 4 of your handshakes are resumed, you need to adjust the numbers. Your mileage may vary but the computational cost for enabling perfect forward secrecy with an ECDHE cipher suite seems a small sacrifice for better security.

---

1. Perfect forward secrecy is an enhanced version of forward secrecy. It assumes each exchanged key are independent and therefore a compromised key cannot be used to compromise another one.
2. For example, this is the case of the implementation I have proposed for stud to enable sharing of tickets between multiple hosts.

A while back I wrote some nodejs that mish-moshed email and web 2.0 long-poll action into a very ugly, but fairly up-to-date showing of debian changes. That is over on my server here. The code s fairly simple, so I also wrote a python consumer here. Since it s so simple, I ve pasted it below, too. Feel free to use (but please not abuse) my server :)

#!/usr/bin/env python
import time
import urllib
import json
service = "http://pault.ag:8080/tail"
lastts  = 0
def loop():
        global lastts
        while True:
                f = urllib.urlopen("%s?since=%s" % (service, str(lastts)))
                msgs = json.loads(f.read())
                for x in msgs['messages']:
                        print x['text']
                        if lastts < x['timestamp']:
                                lastts = x['timestamp']
loop()

This week-end, after a few week-ends more targeted on real life activities (country house fall works, 70km ultra run preparation and ultra run week-end), I spent most of Sunday working on two important uploads of packages I'm involved in. So, as of Sunday evening, samba 3.6.1 is now in unstable. This is the first 3.6 version to land there, after earlier versions were in experimental while Steve Langasek was working on multi-arch support and dh7-like debian/rules transition in unstable, with 3.5 versions. Merging together changes in 3.5 and 3.6 branches has been a bit painful. I guess I had it right (thankfully, I merged 3.5 packaging changes from time to time to the 3.6 branch). If there are problems with 3.6 packages, anyway, you know what to do. I also worked to package the new version of pytrainer, a sport activity logging tool. pytrainer is maintained by the "pkg-running" team, aka No l K the, Ralf Treinen and /me. This is the software I use for keeping track of all my running activities. We have a very good link with our upstream and I even recently brought several translation updates by involving Debian translators in the loop. While working to integrate version 1.9.1 (we had 1.8.0 up to now in unstable), I also cleanedout things here orthereand I'mquite happy with the result. More testing will of course be appreciated.

The Comprehensive R Archive Network, or CRAN for short, has been a major driver in the success and rapid proliferation of the R statistical language and environment. CRAN currently hosts around 3400 packages, and is growing at a rapid rate. Not too long ago, John Fox gave a keynote lecture at the annual R conference and provided a lot of quantitative insight into R and CRAN---including an estimate of an incredible growth rate of 40% as a near-perfect straight line on a log-log chart! So CRAN does in fact grow exponentially. (His talk morphed into this paper in the R Journal, see figure 3 for this chart.) The success of CRAN is due to a lot of hard work by the CRAN maintainers, lead for many years and still today by Kurt Hornik whose dedication is unparalleled. Even at the current growth rate of several packages a day, all submissions are still rigorously quality-controlled using strong testing features available in the R system. And for all its successes, and without trying to sound ungrateful, there have always been some things missing at CRAN. It has always been difficult to keep a handle on the rapidly growing archive. Task Views for particular fields, edited by volunteers with specific domain knowledge (including yours truly) help somewhat, but still cannot keep up with the flow. What is missing are regular updates on packages. What is also missing is a better review and voting system (and while Hadley Wickham mentored a Google Summer of Code student to write CRANtastic, it seems fair to say that this subproject didn't exactly take off either). Following useR! 2007 in Ames, I decided to do something and noodled over a first design on the drive back to Chicago. A weekend of hacking lead to CRANberries. CRANberries uses existing R functions to learn which packages are available right now, and compares that to data stored in a local SQLite database. This is enough to learn two things: First, which new packages were added since the last run. That is very useful information, and it feeds a website with blog subscriptions (for the technically minded: an RSS feed, at this URL). Second, it can also compare current versions numbers with the most recent stored version number, and thereby learns about updated packages. This too is useful, and also feeds a website and RSS stream (at this URL; there is also a combined one for new and updated packages.) CRANberries writes out little summaries for both new packages (essentially copying what the DESCRIPTION file contains), and a quick diffstat summary for updated packages. A static blog compiler munges this into static html pages which I serve from here, and creates the RSS feed data at the same time. All this has been operating since 2007. Google Reader tells me the the RSS feed averages around 137 posts per week, and has about 160 subscribers. It does feed to Planet R which itself redistributes so it is hard to estimate the absolute number of readers. My weblogs also indicate a steady number of visits to the html versions. The most recent innovation was to add tweeting earlier in 2011 under the @CRANberriesFeed Twitter handle. After all, the best way to address information overload and too many posts in our RSS readers surely is to ... just generate more information and add some Twitter noise. So CRANberries now tweets a message for each new package, and a summary message for each set of new packages (or several if the total length exceeds the 140 character limit). As of today, we have sent 1723 tweets to what are currently 171 subscribers. Tweets for updated packages were added a few months later. Which leads us to today's innovation. One feature which has truly been missing from CRAN was updates about withdrawn packages. Packages can be withdrawn for a number of reasons. Back in the day, CRAN carried so-called bundles carrying packages inside. Examples were VR and gregmisc. Both had long been split into their component packages, making VR and gregmisc part of the set of packages no longer on the top page of CRAN, but only its archive section. Other examples are packages such as Design, which its author Frank Harrell renamed to rms to match to title of the book covering its methodology. And then there are of course package for which the maintainer disappeared, or lost interest, or was unable to keep up with quality requirements imposed by CRAN. All these packages are of course still in the Archive section of CRAN. But how many packages did disappear? Well, compared to the information accumulated by CRANberries over the years, as of today a staggering 282 packages have been withdrawn for various reasons. And at least I would like to know more regularly when this happens, if only so I have a chance to see if the retired package is one the 120+ packages I still look after for Debian (as happened recently with two Rmetrics packages). So starting with the next scheduled run, CRANberries will also report removed packages, in its own subtree of the website and its own RSS feed (which should appear at this URL). I made the required code changes (all of about two dozen lines), and did some light testing. To not overwhelm us all with line noise while we catch up to the current steady state of packages, I have (temporarily) lowered the frequency with which CRANberries is called by cron. I also put a cap on the number of removed packages that are reported in each run. As always with new code, there may be a bug or two but I will try to catch up in due course. I hope this is of interest and use to others. If so, please use the RSS feeds in your RSS readers, and subscribe to the @CRANberriesFeed, And keep using CRAN, and let's all say thanks to Kurt, Stefan, Uwe, and everybody who is working on CRAN (or has been in the past).

You make backups? That s great! But are they usable? The very day you will need your backup to restore your infrastructure, are you sure this backup you make three months ago contains the only file you need to restart your production environment? Are you sure this backup is not corrupted? Are you sure you do not store irrelevant or empty files instead of the ones you will need one day? Brebis is a fully automated backup checker. Brebis is written in Python 3 (>=3.2) and comes under the GPLv3 license. The current version is 0.4 (direct download). Some features (extensive list of features available here):

• Support of tar files, compressed with gzip or bzip2 or not, zip files, gzip or bzip2 files and uncompressed trees of files.
• Identify corrupted archives, unexpected size or type for an archive, associated wrong hash sums, Unix rights and owner users/groups of the archive thanks to a list you provide.
• Inside the archive, identify missing files, unexpected ones, unexpected size of a file, wrong associated hash sums, unexpected mode, type or owner users/groups for a file thanks to a list you provide or generate from a given archive.

I have just released version 0.22 of Obnam, my backup application. Snippet from the NEWS file below. This version fixes a couple of bugs that could be said to be of the brown paper bag variety. USER VISIBLE CHANGES:

• Obnam now reports its current configuration in the log file at startup. This will hopefully remove one round of "did you use the --foo option?" questions between developers and bug reporters.

BUG FIXES:

• The repository is now unlocked on exit only if it is still locked.
• A wrongly caught GeneratorExit is now dealt with properly.
• Keyboard interrupts are logged, so they don't show up as anonymous errors.

CHANGES RELEVANT TO DEVELOPERS ONLY:

• setup.py has been enhanced to work more like the old Makefile did: clean removes more artifacts. Instructions in README have been updated to point at setup.py.
• Compiler warning about _XOPEN_SOURCE re-definition fixed.
• Tests are now again run during a Debian package build.

Happy. This is how I feel after I ran the "Le Puy-Firminy" night race last Sunday. 70 kilometers (mixed roads and trails), 1500 meters positive slope, close to my birth town, St-Etienne (the track on Garmin Connect unfortunately has bugs for the profile, sorry for this....this is apparently a bug in Garmin Connect as pyTrainer shows the track very well. And running this by night, starting at midnight and arriving at....09:16 the next day. A full night running. Such "ultra" experience is completely different from marathon running. In marathons, you mostly try keeping a constant pace all along the race, running very close to your limits all along the race. Very long distances involve managing much more than keeping a constant pace. Being able to run (and walk) for many hours requires being very careful at the start of the race, controlling the pace and save energy for the last part of the race. Climbing is most of the time done by walking (except for the very first runners) and going down for kilometers is very hard for legs, even at slow paces. Night running is also making things a lot different. Particularly in a quite small race like this one, it means running alone most of the time. And, by alone, I really mean alone. You and your head lamp, that's all. I am very happy about the way I managed this race. I reached the 32km mark, where an important food/drink point was organised, in a little bit more than 3 hours 15 minutes, where I stopped about 7-8 minutes. That was followed by about 5 kilometers downhill, at 6%, on a paved road, which is really killing legs. The marathon distance was reached in about 5h05, more or less what I planned, but that race is known to be harder in its second half. And completing a marathon, *then* knowing that you still have 2/3 of a marathon to run is kinda challenging..:-) Another important moment of the race was the 55 kilometer mark. This, because this was the longest distance I ever ran in a single race (in March, for the Paris Ecotrail race). Of course, the longer you run, the harder are legs and what was expected happened to me: I had cramps in both legs, at the worst moment, around km 64, when the track brutally goes down for 150 meters in a small canyon, then goes up for about 200 meters. Indeed, I completed kilometer 66 in....22 minutes (I see my marathon runners friends laughing here). This is indeed where you know if you're strong and motivated enough : not abandoning, continue despite cramps, waiting for them to disappear...and finally complete the race. It was really worth it anyway : running by night is really magic. I still remember the though moments at 5am, in the moonlight, alone on a road...and so happy to be there..:-) That race was the last one for me this year. I followed my plans (the only regret being not beating my record at Berlin marathon). Next year plans include two marathons: probably Caen ("Les Routes de la Libert " along the D-Day beaches in Normandy) in June and another one during Fall. I'll also push my limits a bit further with the 80km race of Ecotrail, arriving at Eiffel Tower first floor after running through forests in the SW area of Paris....and probably again that 70km race in November. Once you've tried ultra races, you don't want to stop..:-) Until the end of the year....recovery...and training. After all, Ecotrail is only in 4 months..:-)

The German Linux Magazine runs a sponsored an "Open Source Lounge" at CeBIT each year. Last year I put in a proposal for DAViCal and it got accepted! With some airfare support from InternetNZ I got to showcase my Free Software project at the largest IT trade fair in the world.If you have an open source project to promote I can't recommend this highly enough. Below is a review of my experience at CeBIT early this year. This is long overdue for posting, and I'm prompted now because submissions are now open for the Open Source Project Lounge at CeBIT in 2012. Apply now.The German Linux Magazine runs a sponsored an "Open Source Lounge" at CeBIT each year. Last year I put in a proposal for DAViCal and it got accepted! With some airfare support from InternetNZ I got to showcase my Free Software project at the largest IT trade fair in the world. If you have an open source project to promote I can't recommend this highly enough. Below is a review of my experience at CeBIT early this year. This is long overdue for posting, and I'm prompted now because submissions are now open for the Open Source Project Lounge at CeBIT in 2012. Apply now. DAViCal at CeBIT 2011 CeBIT in Hannover is said to be the largest trade fair in the world, attracting over 300,000 visitors during it's five days. Late last year a DAViCal user in Germany suggested that I apply for a free booth for DAViCal in the Linux New Media Open Source Project Lounge . When DAViCal was accepted, I realised I needed some funding to help me travel around the world to attend, so I applied for a grant from InternetNZ who were kind enough to agree to cover part of my travel costs, and I was on my way. Germany in March is cold, especially for me coming from Summer! My travel allowed for a couple of days in Germany before CeBIT because that was when I could get the cheapest flights, and I wanted to have a little time to recover from the journey. Everyone had warned me to pack my winter woollies, and they were definitely needed! I stayed with a friend in Hamburg for two days and on the the second day we walked through the frozen park, past the frozen lake and over the frozen streams to see the Attraktor Hackerspace in Hamburg Nord where the CCC also hold their meetings a very impressive hackerspace in a repurposed bank (including the vault :-) with several separated areas for talks, meetings and workplaces. The day before CeBIT I travelled to Hannover to take a look at my booth space, fetch exhibitor passes for myself and volunteers and generally prepare to do battle with the crowds. The following day the fair started and it was up at 6:30 to get ready and catch the 7:38 train out to the fairgrounds. Although the fair opens at 9:00 there was always something to do between eight o'clock or so when I arrived at my booth and when the attendees started wandering past.
I was fortunate to have two volunteers for my booth who were there all week, as well as a couple more who turned up on the first two days. Not only did this mean that I got to spend a few hours during the week actually wandering the fairgrounds, but that I had some knowledgeable native german speakers for the occasional visitor who could not speak English. DAViCal has been translated into a dozen languages, and there had been some extra work put in to update the German translation before CeBIT also. As well as showing DAViCal, I was also able to demonstrate a new project at the fair which was aCal - a CalDAV Calendar Client for Android which I had released into the market just a few days beforehand for a token sum (it is licensed GPL v3 or later and the source code is available on gitorious.org). Having the smartphone devices available was great for giving live demonstrations, and I used the timetable for events at the Open Source Forum across the aisle from the Open Source Lounge to populate a calendar that we shared among a variety of devices. The first day was really the calm before the storm, and we saw lots of people asking what we were about, and had some good conversations with people wanting to know more, or telling us they used the software and were very happy with it.
CeBIT closes the gates at 18:00 with the visitor supply drying up pretty quickly around then and the secret lives of the exhibitors are revealed with people starting to relax and joke, and beer or wine starting to come out and some booth parties kicking off... if you have the stamina! I didn't, so it was off back to the train, to Hildesheim, to dinner and to bed. That first day blurred into the next, and the next and by Friday I was starting to lose my voice with all the talking I had been doing. I was visited by a chap from Posnan University who are a DAViCal user and he invited me down to the Polish stand to tell me about what they do there, and he agreed that they would love to help get the Polish translation improved. Another DAViCal user turned up with some bavarian wheat beer and a special beer glass for it by way of thanks. In some spare moments I fixed a bug in aCal's handling of character sets and uploaded a new version, so that we could use umlauts in events. Many people came past to talk to us, some of whom want to help with them project or have ideas for interesting things to do with DAViCal, some were already users of DAViCal and some went away thinking that they would be in the future. The last day of CeBIT is a little different: it's a Saturday and the doors are opened to the public and the minimum age is lowered to allow children to attend the event. I had been warned that this day is a madhouse, and it did indeed seem to be so for many booths. For DAViCal it was probably quieter than the day before, I think perhaps because calendar server software is inherently less sexy than many of the other things on display. We still had plenty of great discussions with interested people nonetheless and to be honest I was fairly happy to be spared the further exhaustion that had been threatened. Sunday was spent recuperating: discovering that Hildesheim has a great little restaurant that does traditional german pancakes for breakfast and then wandering around the small city soaking in the sunshine that I'd seen through the windows outside all week. On Monday I caught the train to M nchengladbach to meet with an organisation that might provide support for DAViCal in Germany, but who hadn't been able to come to the fair to see me due to illness. I was encouraged to spend the night in Aachen a beautiful little city , which I did, arriving around sunset and I spent a couple more days before flying home being intensely antisocial to recover from the furious week beforehand. Is CeBIT worth it? CeBIT seemed to me to be quite a different business model, or perhaps on a different scale. I've seen trade fairs in New Zealand for other purposes, but not to showcase software and services in quite this way. To give an idea of it's scale, consider that I had a tiny booth in a hall that was probably four times the size of the TSB Arena, and CeBIT included around 20 such buildings , packed with exhibitors, with free buses to get around the campus, acres of multi-storey parking buildings, two train stations, and so on. The scale of the event is incredible. As a result of this scale, CeBIT boasts impressive visitor numbers, and while a visitor will usually attend with a specific area of interest in relation to their business they will also wander the fair to see other areas of more personal interest, or just to see what is around. Open Source is a specific area of interest to a significant percentage of business in Germany, and Deutsche Messe, the fair operators, recognise the value of having an open source area as a draw for visitors, with the primary open source area placed in Hall 2, directly off the main north entrance. Within the open source area, the Open Source Project Lounge , where DAViCal was located, is a series of booths sponsored by Linux New Media AG. Projects in the Open Source Lounge are selected by a jury of Linux New Media, Deutsche Messe and several community advisors, so as such there is a range of interesting projects on show and the draw of any given project has a flow-on effect to the others. As an example, at one point while briefly minding the adjacent stand for the OpenEmbedded project I was unable to help an inquiring visitor, but I was able to talk about DAViCal with him until the exhibitor returned to answer his question. His interest in DAViCal was definitely increased in this process, and I'm sure that many people came into our area of the lounge attracted by a specific exhibitor and moving on to see some of the others. Outside of this association with open source, however, CeBIT offers something which general free software events cannot: an association with mainstream software and services. This presentation of Open Source alongside IBM, SAP, HP, Oracle, Software AG, Apple, Microsoft and so forth makes inclusion at this event particularly valuable. Free software solutions can have good brand recognition within the open ecosystem itself and yet be practically unheard of outside it. Most traditional methods of communication with suppliers don't work well with Open Source projects: a request for proposal will sail silently by, unless noted by a related commercial entity. In general there is no sales department, and marketing is frequently a desultory hit or miss affair. The fair is different. The fair is about talking with people. While there is still plenty of collateral marketing with brochures, signs, presentations and giveaway knick-knacks those things are just there to bring people into range: the real action happens when you engage a person in conversation, and at that point a humble free software project can be on an equal footing with a larger booth staffed with eager young salesmen. Of course there are a number of places where free software can get a booth. Linuxtag is a German example where there are many booths for free software projects, linux.conf.au also offers booths to free software projects during it's more outreach Open Day and software freedom day events happen all around the world where booths are available, but the audience arriving at these events are all largely pre-sold on openness and free software. So in presenting this broad blend of people, in a way in which free software projects can present on a roughly equal footing with their commercial brethren, CeBIT is an opportunity not to be missed. The numbers speak for themselves, too: traffic to the DAViCal websites has increased by about 50% around CeBIT with 25% coming from Germany, but significant increases also from France, Netherlands, Italy, Switzerland and Poland. Traffic to the DAViCal wiki has doubled over the last 12 months in a steady increase to around 200,000 page views each month. This sudden increase to around 10000/day in March, with some days during CeBIT peaking at over 20000/day The Future I won't be returning to CeBIT to represent DAViCal in Hannover next year as the sponsored booth is pretty much a one-time thing and the costs involved in purchasing a booth for attendance at the fair are significant (around NZD$15000 for a small 3m x 2m stall). It's possible that I will return next year in a different capacity, as one of the larger stand organisers has confidentially indicated he will invite me to attend as part of an Open Source Apps area that he is considering running on his stand, somewhat along the lines of the Open Source Lounge . Time will tell, I guess, but if invited I think I would definitely go for that. I will definitely be suggesting to a few specific free software projects that they should apply for the Linux New Media opportunity when it comes around again. Koha is one project that immediately springs to mind, but of course there are many, many worthy free software projects and this opportunity seems to be little-understood outside of Germany. If I do convince a project to apply, and they are successful, I will also try and give them some assistance and background knowledge to understand the fair, and how best they can take advantage of the opportunity it offers. Some basic tips would be:

• Book accommodation early, a small apartment or B&B is good. CeBIT accommodation prices are exceptionally high 3 or more times normal rates. There are companies that specialise in renting apartments for the week of CeBIT which are more reasonably priced.
• The fair is in Hannover , except that really it is some distance to the southeast. Exhibitors tickets provide free transport within greater Hannover for the whole week, so you don't actually need to be that close. Options like Hildesheim, a city of some 120k people south of Hannover (where I stayed), are also good although they add a small transport cost.
• Have a pop-up banner for your project.
• Develop a slideshow which tells people about your project and which can just be left running on a larger screen.
• Have a flyer you can hand out to interested people.
• Get at least one committed person to assist on the stand for the whole week.
• Get some more volunteers to assist on the stand for one day each.
• Pace yourself: get to bed early and try not to overdo the partying it's a long week!
• If you want to take a look around the fair don't wait until Friday or Saturday do it on Thursday or earlier.

and finally... I would like to express my appreciation to InternetNZ for the grant to partially cover my travel costs to Hannover, making my attendance at this outstanding event much more achievable. My thanks also to Britta Wulfling who supported all of the projects in the Open Source Lounge. My friends Alexander & Meike in Hildesheim who supplied somewhere for me to recuperate, and accompanied me to the fair every day to run the Debian booth. Thanks also, of course, to the German Linux Magazine for selecting DAViCal for a free booth, and to Benny who pointed the opportunity out, encouraged me to apply, and came along and helped out for the whole week.