This past weekend was tiresome and this week will be more of the same. See, I moved yesterday to our new house. We have much unpacking to do and sleep to catch up on. Add to that that we don't have cable or Internet yet, I have to pick up my car from the shop, go to work, clean the old house and keep feeding the alpacas that aren't moved yet. Oh and Debian will be freezing this week sometime and my NVIDIA team still has a lot of work to do. NMU's are appreciated. Sigh.

There’s an old saying that bad luck comes in threes. Today, I am doing unexpected work because:-

1. one webserver was reinstalled instead of the upgrade I was expecting,
2. another webserver was cracked and defaced (combination of two known security problems that we didn’t fix quickly enough, but that’s the server owner’s call really), and
3. my internet connection keeps going offline for about 20 seconds at a time, which is just enough to stall ssh and VoIP, but not enough to debug.

Hopefully that’s it for today because there are other tasks I want to do. If I’m a bit slow to reply, now you know why! Sorry to anyone who was expecting me to do something else today - I will get back to you as soon as possible.

LUGRadioLive 2008 by sheilaellen (cc-by-2.0) This weekend, I learnt lots of things while at LugRadio Live in Wolverhampton. One thing was the surprising delay between posting something on this site and it actually appearing in the feed on my mobile phone. Another is that I can’t post to my new blog hosting from my mobile phone, which I’ll debug Real Soon Now. So, this is a bit later than when I first wrote it and it’s now one post instead of seven or so… Thanks to some unexplained delay travelling through Birmingham, I walked into LugRadio Live during the Introduction. The venue was generally pretty good, but the stage obstructed the entrance the acoustics in the atrium only seemed to work for the four gents. No idea what they said: I got past the stage into the audience and it finished almost immediately. For the first talk session, I went to see Rufus Pollock of Open Knowledge Foundation introduce a plan for the Comprehensive Knowledge Archive Network. Seems like a good idea. I’ve tons of questions, but I can’t quite get them into words, I don’t know when I’ll have time for this and I’m not sure they really matter anyway. I think I’ll mention CKAN to some librarians anyway and see what they make of it. I expected Emma Jane Hogbin’s “Form an orderly queue, ladies” to start an argument with the usual chix silliness but I was pleasantly surprised by how reasonable the advice was. In fact, the speaker also criticised the “chix” movements, although it appeared she participates in some women-only clubs, so not a 100% win for equality there. Sadly, much of the talk has been overshadowed in my mind by the memory of a giant furry racoon walking in unexpectedly, so I’ll probably grab the video of the LRL-USA version sometime soon. James Hooker’s talk titled “Taming the dragons — entrepreneurship and VCs” launched venturex as described on his own site already (along with more talk descriptions). It was an interesting demo, but it requires hackers to sell some votes in their companies to Venture Capitalists, which I believe is a bad thing for free software developers to do. We need to look more at a form of social entrepreneurism.</soapbox> I tried to ask a question, but the terrible atrium acoustics did funny things with my not-so-good hearing and I lost my way somewhat. At the end of that talk, I got chatting to an interesting web developer from Leicester who also forsook The Gong-a-Thong Lightbulb Talk Extravaganza and headed up to the Lightning Stage for Robert Collins and the Bzr talk. As well as some glimpses of how it’s changed since forking from tla, it was interesting to see a real (imperfect) demo and a non-Emacs version control GUI. The web interface for casual users to submit patches sounded very interesting and I also learned that some people pronounce “svn” like “Sven”. Most things that Robert thought were benefits sounded like drawbacks to me, so I’ll stay with git for now. Steve Lamb’s Green IT talk was the last presentation I saw. This talk really disappointed me because it seemed to be skewed towards the corporate governance nonsense instead of seeing Green IT as a vital pragmatic step, mentioning points I’d seen put more clearly elsewhere, as well as advertising Vista virtualisation and some panoramic webcam from Microsoft (who employ him) that doesn’t work with any free software, according to a deserved verbal shoe-ing in the Q+A. Only thing I remember that seems useful: charging from USB is more efficient than using wallwarts. Is that right? Finally, the main event: LugRadio Live and Unleashed. It opened with the shock announcement that LRL will continue into 2009, as announced elsewhere already. The rest of the madness will presumably appear online shortly and I don’t remember it well enough to do it justice… A tech conference crossed with a rocking gig by the strangest boyband ever, with a cheerleading racoon and some very cool people. I’ll try to be at LRL 2009. Will you be there? Were you at LRL this last weekend?

Thanks to the Virtuzzo developers for forward porting the OpenVZ patch to 2.6.26. It uses a lot of the already merged namespace features (For interested peoples linux-next carries interesting sysfs patches). The openvz upstream merge statistic is impressive. The namespace solution allows low overhead, while still running multiple Linux distributions in individual containers on the same box. Control over the network vitalisation is gained as a resource management for CPU power, I/O bandwidth and disk space. Live migration including snapshotting is possible too. The Debian 2.6.26 Linux images will feature not only better Xen vitalisation support, kvm port to new archs, but also an opvenvz flavour. Please don't forget to install proper vzctl userspace support as the correct dependencies have not yet been added. Supported archs will start with both x86 and the ia64 archs. Tomorrows linux-2.6 Debian trunk snapshots will already build openvz. Thanks for your feedback. P.S.: 2.6.26 is the targeted kernel for Lenny, we hope to convince Debian installer people to pick it up soonest - 2.6.25 is a not so bad backup plan as release hasn't fully approved 2.6.26 before extensive unstable testing.

Last week, Stanford University hosted Cartel, a gathering of several schools that share similarities of infrastructure and IT problems. I was one of the coordinators, handled most of the content for the web site, helped prepare the agenda, and presented for three of the segments. It's considerably more work hosting and coordinating one of these than just attending one, even with the travel. Jeff Altman and Derrick Brashear, the other two OpenAFS gatekeepers, were also in town for half of Cartel and stayed through Friday, so we went out to dinner several times, played a great deal of Fluxx, talked about the state of the world, and caught up. This was all great and very informative, but I'm also an introvert, which means that no matter how much I'm enjoying social interaction, it's also extremely tiring. I'm still fairly wiped; I'm getting more done (and got more done last weekend) than I really expected, but I expect I'll be paying the price all the way through this week. (And then I have more company from out of town that I've been looking forward to for months, but which will then take its own toll, which means it's likely I'm going to be exhausted until well into August.) So, I'm currently looking at all the things I want to do and trying to tell myself that not only is it okay that they're not all going to get done right away, but I need to make a concerted effort to take time to relax, try to work less than 40 hours this week (after working 56 last week), and spend more time reading. Of course, writing reviews is one of the other things that I'm currently a bit behind on.... Debian is freezing for lenny next weekend. If I have a few moments, I may do final uploads of OpenAFS (to clarify that hppa isn't a supported platform) and kstart (a long-awaited new upstream release that adds a flag saying not to get forwardable tickets, needed if one has a krb5.conf configuration saying to get them and a site policy that says you can't). gnubg could stand another upload, but I probably won't get to that. The Shibboleth packages are all in good shape except that they don't all have complete copyright files for all the Autotools helper stuff, which is very not important. Thankfully, the freeze is basically meaningless for Lintian, which will continue apace (and Adam D. Barratt continues to take much of the load off by doing a ton of commit work), and means that Debian Policy work should actually slow. My intention is to make the next normative release of Policy shortly after the lenny release, which gives us plenty of time to work on more changes for the next version. I plan on somewhat ignoring both for a bit while I catch up on other things, since I released Lintian 1.24.2 on the 13th (which I see I never announced here — whoops). In other news, I finally started the process of moving services from systems I own and have to fix to systems where someone else owns the hardware and has to fix it when it breaks by buying a VM from Panix. I still need to sort out my DNS situation and get more direct control over my zone file now that I have somewhere I can run my own DNS server so that I can start moving services there, but so far, so good. I'm extremely impressed by their service and capabilities and already have all of my Git repositories on the system and gitweb set up once I get DNS updated.

I'm envisioning a graphical app that displays a file. Like a pager, the up and down arrows move through the file. But the left and right arrows move through time. As each successive change to the file is displayed, the committer's name appears in a column to the left of the lines changed in that commit. Hover the mouse over it to see the commit message. Names of old committers will fade out as time advances, but still be visible for a while. (A menu option will disable the fade out entirely.) A nice bonus feature would be to allow opening multiple windows, with multiple files from the same repo. Moving back and forward in time would affect them all at once. A nice, but getting harder feature would be to have a horizontal timeline at the bottom, including branches, so you could click on a specific branch to visit it. (Without this, when passing a fork or merge point, it would have to choose a branch heuristically?) A tricky subtle feature would be to attempt to keep the current code block centered in the display as lines are added/removed from the file, adjusting scroll bar position to compensate. There seems to be a gannotate for bzr, that may do something like this. Offline so I can't try it. Google-and-caffine-fed update: bzr gannotate is closest to what I envisoned, though without a few of the bonuses (fade-out, smart scrolling, multiple files). qgit's "tree view" includes the same functionality, but the interface isn't as nice.

I'm envisioning a graphical app that displays a file. Like a pager, the up and down arrows move through the file. But the left and right arrows move through time. As each successive change to the file is displayed, the committer's name appears in a column to the left of the lines changed in that commit. Hover the mouse over it to see the commit message. Names of old committers will fade out as time advances, but still be visible for a while. (A menu option will disable the fade out entirely.) A nice bonus feature would be to allow opening multiple windows, with multiple files from the same repo. Moving back and forward in time would affect them all at once. A nice, but getting harder feature would be to have a horizontal timeline at the bottom, including branches, so you could click on a specific branch to visit it. (Without this, when passing a fork or merge point, it would have to choose a branch heuristically?) A tricky subtle feature would be to attempt to keep the current code block centered in the display as lines are added/removed from the file, adjusting scroll bar position to compensate. There seems to be a gannotate for bzr, that may do something like this. Offline so I can't try it. Google-and-caffine-fed update: bzr gannotate is closest to what I envisoned, though without a few of the bonuses (fade-out, smart scrolling, multiple files). qgit's "tree view" includes the same functionality, but the interface isn't as nice.

About one week ago, I received my OpenMoko Freerunner. This is an openly developed mobile phone that runs purely on Free Software. So this is what I have to tell about it.The hardwareIt was smaller than I thought, and is quite light. My girlfriend says it s ugly, but I m fine with the look of it. Besides being a GSM-phone, it comes with some nice gimmics: GPS, accelerometer, WLAN. The touchscreen works fine, although I don t have anything to compare it with.The softwareThe system it comes with, even after upgrading, is still very rough. It mostly works for doing phone calls and SMSs, but there are a number of unsolved quirks that prevent me from using the Freerunner as my sole phone for now. The suspend mode is left too often, resulting in a battery life of about eight hours, and there are issues with the audio for the conversation partners, who will hear static and echoes. But, as this is free software, there is hope that this will be fixed eventually.DevelopmentThe OpenMoko distribution is based on Openembedded, which uses bitbake for building software. So if I got it right, and this is not sure, because documentation is rare and spread, there is the git repository at git.openmoko.org, which is a copy of the openembedded git repository. This contains bitbake recipies for all the packages, which includes where they can be downloaded, the package metadata (such as dependencies and version numbers) and sometimes patches. These recipies reference upstream tarballs or subversion URLs. For the native OpenMoko applications, the source is in the OpenMoko subversion repository.One of the suggested ways of compiling software for the FreeRunner is by using a toolchain tarball, that can easily be extracted somewhere and used to build the software from the subversion repository, or other (hopefully autoconf ed) software. This builds the binaries, but does not produce proper .ipk files, so no version number or dependencies.The other way is the full openembedded setup, made easy using the MokoMakefile. This, automatically, fetches and builds everything needed for the cross compiliation and all available packages, producing the same output as can be found on the openmoko servers. Setting this up requires about 6 gigabytes of storage and takes over a day the first time, but then hacking the phone is relatively painless, as it resolves dependencies and is self-contained.The communityFor a free software project, the state of the community is very important. The OpenMoko seems to suffer from a rush of interested people on the mailing lists, so it s hard to follow real development in a mass of frequently asked questions and nice ideas from people who have neither an OpenMoko phone nor wil do any coding.On the other hand, it s not easy for new contributers. I have written some code that make sure the phone can handle numbers such as 0172/123 456 instead of the official +49172123456 in the phonebook and the SMS app, something that other users have complained about as well. But no one could tell me where and how I should submit my patches, and the mail to the mailing list with the patches and the bug report is unanswered. It is not clear, at least to me, who is responsible for what part of the project quite different to what I m used to from Debian, where there is a clear list of maintainers for each package, and a well known way of submitting patches (by going through bugs.debian.org).For interested users, I have published my branch of the git repository at git.nomeata.de, and I will hopefully add more features and bugfixes later at least when I find out how to properly contribute to OpenMoko.

I'm in Portland, Oregon for the week where I'll be at OSCON. I'll be giving two talks on the final day of the conference (July 25): the first will be a 15 minute keynote on Revealing Errors at 8:45 in the Portland Ballroom; the second is a full-length normal talk on Selectricity at 11:35AM in Portland 255. It will be my first long-form talk about Selectricity and I'm looking forward to it. Because myself, a few Free Software Foundation staff members including Campaign Manager Joshua Gay, and quite a few FSF associate members will be in town, we're going to hold a small FSF Associate Members event in Portland (the first outside Boston!). It's going to be in the form of a pizza party with a few small talks from FSF folk including myself. Here are the details:

FSF Associate Members (& friends!) Event

July 22nd 6:30-9:00PM

Old Town Pizza

226 NW Davis St

Portland, OR 97209

It's free and open to all but is designed to provide a forum for members and friends. If you are an FSF member, please consider coming. If you're not a member yet, please don't let it keep you away; staff will be able to sign up new members there. RSVPs to Deborah Nicholson aren't necessary to attend but would be welcome. I'll be heading to Seattle right after the conference for a few days. If you would like to meet up in Seattle or Portland this week, please don't hesitate to get in contact.

Once again, Wikimania was wonderful. I gave my scheduled talk on Autonomo.us and network freedom and network services. I also filled in for a few speakers to give a "Zotero for Wikipedians" demo and to say a few words about the BY-SA/FDL work as part of a Creative Commons panel. Perhaps the most memorable part of the conference was the writing and performance of I Will Revise. A couple days before the conference, a small group of Wikipedians -- The Difftones -- wrote the song at a karaoke bar in Alexandria. We had a wonderful time leading a room full of lightning talk attendees in song and a final rendition by a massive, fully-packed, stage at the party on the final night! It's online on meta.wikimedia.org. You should feel free to revise it, add verses, and improve it!

Today anibal(thanks!) uploaded xscreensaver 5.05-3, this release fixes the XRandR issue that a lot of people reported since the introduce of sanity code in 5.05 for XRandR (that are some quite RCs and important bugs). 5.06 is out now but we couldn't wait more to get this RCs closed, in a week or two this new release will be ready and in the archive.

I have just bought a EeePC 701 [1], I chose the old model because it’s significantly smaller than the 90x series and a bit lighter too and it had Linux pre-loaded. Also it was going cheap, while I am not paying for it I give the same attention to saving my clients’ money as to saving my own. I ruled out everything that was heavier or larger than an EeePC 901 and everything that cost more than $700. That left only the Linux version of the EeePC 901 (which I couldn’t find on sale) and the EeePC 701 as my options. I also excluded the EeePC 900 because it is bigger and heavier than the 701 but has the same CPU (and therefore can’t run Xen). In terms of it’s prime purpose (a SSH client) 96*22 characters is the size of a konsole screen with the default (medium) font size when the window is maximised, that is 5% more characters than the standard terminal size of 80*25 but the smaller number of lines is a problem. When using the small font I can get 129*29 which I find quite comfortable to read (it would be impossible for me to read withut glasses - which means having almost average vision for someone in their 30’s). Then I can get 129*31 if I dismiss the tool bar at the bottom of the screen and could probably get another couple of rows if I removed the tabs that Konsole uses to switch between sessions. That would only be viable if using screen extensively as a single session without the ability to switch between programs is not particularly useful (I don’t think that ALT-TAB is adequate for switching between terminal sessions). When running Debian I can get 130*32 with the same font due to smaller window controls, but I’ll write more about converting to Debian in another post. Note that while the OS that ships with the Linux based EeePC machines is based on Debian, it is heavily customised and has some notable differences from a typical Debian install. It has some proprietary software, and uses unionfs for the root and /home filesystems. The first issue is that Console (the KDE terminal program) can only be accessed from the file manager (via the tools menu or ^t), the machine clearly doesn’t have defaults for someone like me. In principle it’s a multi-user system that can be fully customised, but in practice it’s configured as a single-user machine. Once you have a Console window open you can run “su -” and the root password is the password for the “user” account. I wonder whether I could get more than 42 rows or more than 140 columns of text that is readable. If so then I could have two console windows fully displayed on screen. The screen is bright and clear, this is essential as the number of pixels per character is going to be low for any reasonable amount of text to be displayed on screen. The password that you set when you first use the machine also works for “su -” (in fact that is the only real use as I expect that almost everyone will choose the automatic login option). The display comprises a significant portion of the weight, if the screen is fully open (about 150 degrees) then it will tip over. Even when the screen is not as far open it will tip due to bumps if resting on your lap on a tram. It’s a pity that the screen is connected at the very back of the base, if the attachment point was a bit closer then it would balance better and also be easy to hold with one hand. The depth of the machine combined with the angle at the back makes it impossible for me to get a good one-handed grip from the base, so typing while standing on a moving tram or bus will be extremely difficult (unlike my iPaQ which I can use at full speed on any form of public transport). Inidentally it would be good if there was an attachment point for a wrist-strap, every camera and most mobile phones have them so it would be good to have the same safety feature in a laptop to facilitate use on public transport. Another reason for not using it as a PDA is the fact that it takes about 7 seconds to resume after hibernating (when the lid is closed). The PSU is almost as small as that of a mobile phone! This is a major benefit as in the past I have often stored a Thinkpad PSU at a client site for 9-5 jobs as it is heavy enough that I didn’t want to carry it on public transport. The EeePC PSU is light enough that it won’t be unpleasant to carry, and small enough to fit easily into a jacket pocket. The OS installation is very well done for the basics. It’s easy to launch applications and there is a good selection of educational programs (including the periodic table, planetarium, typing, letters, and hangman, drawing, and a link to www.skoool.com). It’s a pity that they organised the folders according to the area rather than the age, but generally the OS is very well done. Most of the reviews focus on the speed of the CPU, the RAM expansion options, etc, but miss the fact that it is a really nice machine for using as-is. It is a much better machine for teaching children than any of the machines I’ve seen which are sold specifically for children (see my previous post about an awful computer for kids [2]). I believe that you could give an EeePC to any 3yo and have them doing something useful in a matter of minutes! The ability to freely install new software should not be overlooked when considering a computer for children to use. Someone who buys one now could use it for a few years as an ssh client and then reinstall the original OS and give it to a child as an educational toy. It has a program to create OGG video files from it’s built-in camera and mic, at this moment it’s the only device I own that can create OGG files (this is a good thing). OGG compression takes a really long time, the Atom CPU in the 901 and 1000x series would be good for this. It’s a pity that the microphone is directly below the mouse buttons, it clearly records the mouse click used to finish recording. The version of mplayer which is installed to play OGG files can also play FLV files downloaded from youtube with youtube-dl (althrough the file association is not set). When I tried to play a MP4 file from ted.com it only gave audio (the video works on a full Debian/Etch installation). There is a full set of office software, OpenOffice.org, Thunderbird email client, and all the other stuff you might expect. I find that the biggest problem for using it is the size of the keyboard, I don’t think I’ll ever be able to touch-type properly on it. Not only are the keys small but the positions of non-alphabetical keys are slightly different from most keyboards. Another problem is that the space-bar needs to be pressed near the centre, I usually like to press near the end but that doesn’t work. Those issues are all trade-offs of the small size. My T series Thinkpad is reasonably portable and has a great keyboard so I have the serious typing while travelling angle covered. One real mistake in the keyboard design is the lack of a LED to indicate whether caps-lock is enabled (there are four status LEDs, adding number five couldn’t be that expensive), this is a real problem when using the vi editor (which uses letters as editor commands and is case-sensitive). It will also occasionally cause problems when entering passwords. There is a caps-lock indicator on screen, but that is in the toolbar at the bottom of the scren (which I like to dismiss to gain an extra two lines of text). It would be good if I could display the status of the caps and num lock keys in the right side of the title-bar of the active window (the only bit of unused space on the screen). The cooling fan makes an annoying buzz. It’s significantly louder than Thinkpads which dissipate a lot more heat. The other problems are all software, which is OK as I plan to reinstall it. Firstly it is using Debian and shipped with the broken openssl library. There is a GUI for installing upgrades, but it recommends rebooting after installing each one! Naturally I didn’t choose to reboot, I installed the security update #1. Then I clicked on the button to install a BIOS update. It told me that it had to reboot to apply the update and gave only one button (OK), I tried closing the window but it rebooted anyway (fortunately the vi swap file allowed me to recover this post - which I am entirely writing on the EeePC). Aftere booting up again I discovered that the libssl bug still wasn’t fixed and that there was a second udate to apply! Why can’t they have a “apply all updates” button and also have it not automatically reboot? This must be the only Debian-based distribution that forces Windows-style reboots. But that said, while they made some mistakes in their software it generally provides a good user experience

• [1] http://en.wikipedia.org/wiki/Eeepc


• [2] http://etbe.coker.com.au/2008/07/07/awful-computers-for-kids/

Share This

Just in time, at the end of my 3 week vacation, I released the first public version of smuxi! For people who don't know smuxi yet: I have been developing over the last 3 years an IRC client that fits the needs I could not satisfy with irssi. I was using irssi over 4 years and it's the best the IRC client I used so far. Most annoying was that it didn't integrate at all into my desktop experience (such as mouse / clipboard / theming / highlight handling). Thus irssi inspired lots of features and commands seen in smuxi. So here it comes, a flexible cross-platform open-source IRC client for the GNOME desktop, in action:
    Smuxi is built using a great software development stack, composed of: C# / Mono, GTK +,# / GNOME(#) and MonoDevelop. Interested in using or contributing to smuxi?
Head over to the official release announcement on the smuxi project website. For the Debian users and developers among us:
Debian packages for smuxi are not available yet, but will be very soon.

I recently had to setup netconsole in order to diagnose some grsecurity-related suspend/resume problems. The idea is to have the broken machine send its kernel messages to a remote machine via the network.
As a prerequisite, the local machine (the one sending the console messages) must have the following kernel options turned on:

• CONFIGFS_FS
• NETCONSOLE
• NETCONSOLE_DYNAMIC

(The first and last ones are required in order to be able to configure netconsole after boot, through the configfs interface.)The remote machine should be told (using netcat) to listen on a specific UDP port (64001 in this example):

netcat -l -p 64001 -u -s 192.168.1.1 2>&1 tee /root/netconsole.log

Then, running this script on the local machine will turn netconsole on (don't forget to customize the appropriate parameters for your environment):

#!/bin/sh
modprobe configfs
umount /sys/kernel/config 2> /dev/null
mount -t configfs none /sys/kernel/config
modprobe netconsole
mkdir  /sys/kernel/config/netconsole/hostname
echo "xx:xx:xx:xx:xx:xx" >  /sys/kernel/config/netconsole/hostname/remote_mac
echo 192.168.1.1 >  /sys/kernel/config/netconsole/hostname/remote_ip
echo 64001 >  /sys/kernel/config/netconsole/hostname/remote_port
echo 192.168.1.2 >  /sys/kernel/config/netconsole/hostname/local_ip
echo 64001 >  /sys/kernel/config/netconsole/hostname/local_port
echo eth1 >  /sys/kernel/config/netconsole/hostname/dev_name
echo 1 >  /sys/kernel/config/netconsole/hostname/enabled
dmesg -n 8

That's all you need to start seeing messages on the remote machine's screen.
Interested readers may want to look at other ways to configure and use netconsole.

( I love acronyms :-D )

At this point, all of you should know and see how the H D Moore s toys work. Those toys attack SSH public-key authentication using clone keys and online brute force.

Furthermore, many of you know that there are other effects produced by a biased PRNG besides this one.

Strangely, I could not find more of those toys exploiting these aspects. So, I would like to show you a Wireshark patch which attacks Perfect Forward Secrecy (PFS) provided by Ephemeral Diffie Hellman (EDH).
Introduction to EDHLet s put it in plain words (if you know what we are talking about, ignore this and jump to the next heading):
In an insecure communications channel the parties agree a common key to cipher their dialog. This is what happens in SSL (in most of the cases, depending on the cipher suite):

• The server selects a random prime p and a generator g of the field Z*_p (Let s ignore the mathematical properties of these values). So, the components p and g are public.
  
• The server picks a secret random number X_s and calculates Y_s=g^X_s mod p. Y_s is public and is sent to the client (just like p and g).
  
• The client does something similar, selecting a secret random number X_c and calculating Y_c=g^X_c mod p too. The client makes Y_c public by sending it to the server.
  
• The shared secret s is the public key of the other part to the exponential of the own private number, all in p modulus. That is, for the client s=Y_s^X_cmod p and for the server s=Y_c^X_smod p.
  
• With this shared secret the parties can encrypt all the following messages in a secure way.
  
• In the Ephemeral Diffie Hellman (EDH), the private numbers are ruled out, so s is mathematically secure and nobody can obtain it even having access to one of the parties after the aforementioned handshake.
  

The exploit If an eavesdropper can explore the complete private key space (the all possible numbers for X_c or X_s), he/she will be able to get access to the shared secret. With it all the communication can be deciphered. That s what this patch can do.

A Wireshark with this patch and a list of possible private keys will try to brute force the share secret. If one of the parties is using the vulnerable OpenSSL package the communication is totally insecure and will be decrypted.

• The patch for Wireshark 1.0.2 can be downloaded from here.
  
• Debian packages with the patch applied can be found here.
  
• This is a list of all 2¹⁵ possible 64 and 128 bit DH private keys in systems vulnerable to the predictable OpenSSL PRNG described by DSA-1571.
  
• An example of a pcap file can be found here (it was built with a vulnerable client and one of the Moore toys, a hacked getpid by running $ MAGICPID=101 LD_PRELOAD= getpid.so ./vulnerable-openssl/apps/openssl s_client -connect db.debian.org:443 )

The patch was submitted in order to be committed on the Wireshark trunk. There you can find the patch against the on-develop source revision 25765.
Issues that can be improvedWe (the other developers and myself) detected few things to be improved. But we will do nothing for them. So, if you want to contribute with some code, start from these items and submit the patches to the Wireshark s bugzilla:

• When the packets are out-of-order the decipher with stop itself.
  
• The brute force attack should run in a background process (and with a progress bar)
  
• Check the length of the keys before trying to brute force them.
  
• The patch also implements the display of public DH parameters in the packet tree. It s incomplete.

CreditsPaolo Abeni <paolo.abeni at email.it>
Luciano Bello <luciano at debian.org>
Maximiliano Bertacchini <mbertacchini at citefa.gov.ar>

This work was partially supported by Si6 Labs at CITEFA, Argentina.

UPDATE Jul. 21st: See more and updated info here, especially this.

( I love acronyms :-D )

At this point, all of you should know and see how the H D Moore s toys work. Those toys attack SSH public-key authentication using clone keys and online brute force.

Furthermore, many of you know that there are other effects produced by a biased PRNG besides this one.

Strangely, I could not find more of those toys exploiting these aspects. So, I would like to show you a Wireshark patch which attacks Perfect Forward Secrecy (PFS) provided by Ephemeral Diffie Hellman (EDH).
Introduction to EDHLet s put it in plain words (if you know what we are talking about, ignore this and jump to the next tittle):
In an insecure communications channel the parties agree a common key to cipher their dialog. This is what happens in SSL (in most of the cases, depending on the cipher suite):

• The server selects a random prime p and a generator g of the field Z*_p (Let s ignore the mathematical properties of these values). So, the components p and g are public.
  
• The server picks a secret random number X_s and calculates Y_s=g^X_s mod p. Y_s is public and is sent to the client (just like p and g).
  
• The client does something similar, selecting a secret random number X_c and calculating Y_c=g^X_c mod p too. The clients makes Y_c public by sending it to the server.
  
• The share secret s is the public key of the other part to the exponential of the own private number, all in p modulus. That is, for the client s=Y_s^X_cmod p and for the server s=Y_c^X_smod p.
  
• With this share secret the parties can encrypt all the following messages in a secure way.
  
• In the Ephemeral Diffie Hellman (EDH), the private numbers are ruled out, so s is mathematicaly secure and nobody can obtain it even having access to one of the parties after the aforementioned handshake.
  

The exploit If an eavesdropper can explore the complete private key space (the all possible numbers for X_c or X_s), he/she will be able to get access to the share secret. With it all the communication can be deciphered. That s what this patch can do.

A Wireshark with this patch and a list of possible private keys will try to brute force the share secret. If one of the parties is using the vulnerable OpenSSL package the communication is totally insecure and will be decrypted.

• The patch can be downloaded from here.
  
• Debian packages with the patch applied can be found here.
  
• This is a list of all 2¹⁵ possible 64 and 128 bit DH private keys in systems vulnerable to the predictable OpenSSL PRNG described by DSA-1571.
  
• An example of a pcap file can be found here (it was built with a vulnerable client and one of the Moore toys, a hacked getpid by running $ MAGICPID=101 LD_PRELOAD= getpid.so ./vulnerable-openssl/apps/openssl s_client -connect db.debian.org:443 )

The patch was submitted in order to be committed on the Wireshark trunk. There you can find the patch against the on-develop source revision 25765.
Issues that can be improvedWe (the other developers and myself) detected few things to be improved. But we will do nothing for them. So, If you want to contribute with some code, start from these items and submit the patches to the Wireshark s bugzilla:

• When the packets are out-of-order the decypher with stop itselft.
  
• The brute force attack should run in a background process (and with a progression bar)
  
• Check the length of the keys before trying to brute force them.
  
• The patch also implements the display of public DH parameters in the packet tree. It s incomplete.

CreditsPaolo Abeni <paolo.abeni at email.it>
Luciano Bello <luciano at debian.org>
Maximiliano Bertacchini <mbertacchini at citefa.gov.ar>

This work was partially supported by Si6 Labs at CITEFA, Argentina.

Now that D-I beta2 has been released, the next release of D-I *will* very certainly be called a "Release Candidate" and be the final release used in Lenny. So, it's time for our translators to put their work in shape and we have 61 supported languages so far. In short, expect being nagged by /me quite often in the upcoming two months. The current status is:

• Level 1 (core D-I): 20 complete languages (bg, cs, dz, eo, es, fr, gl, gu, ja, ko, lt, mr, nl, pt, pt_BR, ro, ru, th, tr, vi)
• Level 1 + Level 2 (packages with strings used in default installs): 11 complete languages (bg, cs, es, fr, gu, ja, pt, ro, ru, th, vi)
• Level 1-3 (pkgs prompting during default desktop installs or important for desktop installs): 7 complete languages (bg, fr, ja, pt, ru, th, vi)
• Level 1-4 (adding pkgs prompting during other tasks): 7 (the same)
• Level 1-5 (adding important stuff such as apt, dpkg, aptitude): 2 complete languages (fr, vi)

Of course, I expect these to raise up significantly. I posted new calls for updates this week-ed, in the hope people are not tired of /bubulle nagging them constantly. Please note that Level 1 partial completion (the first two "sublevels") is a requirement for a language to be activated in D-I. As of now, we "only" have about 40 languages in that case.

dsyslog 0.3 has been released, with support for postgresql logging targets, and much more. The development of postgresql support, and extensive documentation, has been made possible by Google’s summer of code program sponsorship of Jeff Katz, who intends to contribute even more code to 0.4. It’s presently sitting in NEW, but if you want it now, you can grab it from the dsyslog website.

All being well, as this post appears, I’m on my bike on the first leg of my journey to LugRadiO Live UK 2008 in Wolverhampton, blasting my way past WordCampUK who daftly picked the same day. However, I plan to post a report from LRL, while Dave Briggs will post from WordCUK. Now, shall I heckle Open Knowledge, Community-Community-Community or Beard?