Planet Debian

Jonathan McDowell: Best bluetooth GPS for walking?

Sun, 18 May 2008 10:21:53 +0000

Dear Lazyweb,

What is currently the best GPS chipset suitable for walking? Something I can pair up with my E70 to get tracks for importing to OpenStreetMap is the sort of thing I'm looking for. I can find various reviews that suggest the SirfStar III is best for the low speeds associated with walking, but they're all at least a year old. Has nothing better come along since? What about the SkyTraq Venus 5?

Julien Blache: pommed v1.18: small things

Sun, 18 May 2008 10:21:09 +0000

I’ve just released pommed v1.18, which is mainly a maintenance release.

I’ve added some more USB IDs for Apple external keyboards and relaxed the event devices identification for internal keyboards.

pommed will now happily start on a machine fitted with a keyboard+trackpad assembly that normally isn’t found on this model. This can happen when the topcase of the machine is replaced with the wrong part. I expect this situation will happen more and more often as people buy parts from EBay or similar to repair their laptops.

Julien Danjou: Boarding the Prometheus

Sun, 18 May 2008 08:26:00 +0000

As I said a month ago, my main server Delmak was dying. Well it still runs (proof: you could read this blog some days ago).

Thanks to friends I host for free, they've kindly given enough money to buy a brand new server (C2D E8400, 4 GB RAM, 2x500 GB RAID 1) in order to replace the good old Delmak. This new box has been named Prometheus after the only BC-303 class battleship ever built.

Delmak was used to mainly run as a Web, mail and databases server. I decided to do use this server switch to change the server software I use.

The first mail server I setup was based on Exim 3, courier-{imap,pop}{-ssl,} with userdb files. That was... rough. Later I switched to Exim 4, using vexim, and MySQL as a back-end. That was something like 3 years ago I guess. Since then I never really touched that back. I added spamassassin and clamav filtering some months after, because some users asked for it. That's all.

So this week, I decided to switch away from this configuration. I do not understand Exim anymore anyway, so I decided to use Postfix which I often use and administrate at work. Obviously, I also now use PostgreSQL as database back-end, since it rocks, and since Postfixadmin supports it. By the way, be aware that the Debian package of postfixadmin is crappy (the configuration file is readable by anyone by default, with the database password in it). I also set up postgrey which is quite nice and efficient.

Well, then was time for amavisd-new installation, but I did not do it. Seriously, amavisd-new configuration is a bloody mess, as the language it is written in (yes, Perl).

So I switched to dspam which I heard is nice. Well, it seems to be for now, since it even supports clamav daemon usage directly, which is very very nice because that means I do not have to set up another thing for that.

I also switched from courier to dovecot, mainly because the latter seems to be faster and lighter. I then changed the default virtual_transport to Dovecot LDA. The main advantage of this is that the LDA updates the Dovecot index while delivering. It also supports quota, which I do not use and plug-ins, like the Sieve language for mail filtering.

So I decided to change my procmailrc to a new Sieve filter. My procmailrc is quite small since I only use regex to match lists and some mail address, so it has only something like 12 rules. And well, I did not do it since I discovered after some googling that Dovecot implementation of Sieve is grabbed from Cyrus which does not support variables for now. That means that the following procmailrc code:

:0:
* ^X-Mailing-List: <debian-.+@lists.debian.org>
* ^X-Mailing-List: <debian-\/[^@]+
list-debian-$MATCH/

which will translate to:

require [ "regex", "variables", "fileinto" ]
if header :regex "X-Mailing-List" "<debian-(.+)@"
{
    fileinto "lists.debian.${1}";
    stop;
}

But that won't work since Dovecot Sieve implementation does not support "variables". Well, since I'm not ready to list all the lists I'm subscribed to, Sieve is a no-go for now. I'll stick with procmail.

Russell Coker: Debian SSH Problems

Sun, 18 May 2008 08:02:20 +0000

It has recently been announced that Debian had a serious bug in the OpenSSL code [1], the most visible affect of this is compromising SSH keys - but it can also affect VPN and HTTPS keys. Erich Schubert was one of the first people to point out the true horror of the problem, only 2^15 different keys can be created [2]. It should not be difficult for an attacker to generate 2^15 host keys to try all combinations for decrypting a login session. It should also be possible to make up to 2^15 attempts to login to a session remotely if an attacker believes that an authorized key was being used - that would take less than an hour at a rate of 10 attempts per second (which is possible with modern net connections) and could be done in a day if the server was connected to the net by a modem.

John Goerzen has some insightful thoughts about the issue [3]. I recommend reading his post. One point he makes is that the person who made the mistake in question should not be lynched. One thing I think we should keep in mind is the fact that people tend to be more careful after they have made mistakes, I expect that anyone who makes a mistake in such a public way which impacts so many people will be very careful for a long time…

Steinar H. Gunderson analyses the maths in relation to DSA keys, it seems that if a DSA key is ever used with a bad RNG then it can be cracked by someone who sniffs the network [4]. It seems that it is safest to just not use DSA to avoid this risk. Another issue is that if a client supports multiple host keys (ssh version 2 can use three different key types, one for the ssh1 protocol, one for ssh2 with RSA, and one for ssh2 with DSA) then a man in the middle attack can be implemented by forcing a client to use a different key type - see Stealth’s article in Phrack for the details [5]. So it seems that we should remove support for anything other than SSHv2 with RSA keys.

To remove such support from the ssh server edit /etc/ssh/sshd_config and make sure it has a line with “Protocol 2“, and that the only HostKey line references an RSA key. To remove it from the ssh client (the important thing) edit /etc/ssh/ssh_config and make sure that it has something like the following:

Host *
Protocol 2
HostKeyAlgorithms ssh-rsa
ForwardX11 no
ForwardX11Trusted no

You can override this for different machines. So if you have a machine that uses DSA only then it would be easy to add a section:

Host strange-machine
Protocol 2
HostKeyAlgorithms ssh-dsa

So making the default configuration of the ssh client on all machines you manage has the potential to dramatically reduce the incidence of MITM attacks from the less knowledgable users.

When skilled users who do not have root access need to change things they can always edit the file ~/.ssh/config (which has the same syntax as /etc/ssh/ssh_config) or they can use command-line options to override it. The command ssh -o “HostKeyAlgorithms ssh-dsa” user@server will force the use of DSA encryption even if the configuration file requests RSA.

Enrico Zini describes how to use ssh-keygen to get the fingerprint of the host key [6]. One thing I have learned from comments on this post is how to get a fingerprint from a known hosts file. A common situation is that machine A has a known hosts file with an entry for machine B. I want to get the right key in machine C and there is no way of directly communicating between machine A and machine C (EG they are in different locations with no network access). In that situation the command “ssh-keygen -l -f ~/.ssh/known_hosts” can be used to display all the fingerprints of hosts that you have connected to in the past, then it’s a simple matter of grepping the output.

Docunext has an interesting post about ways of mitigating such problems [7]. One thing that they suggest is using fail2ban to block IP addresses that appear to be trying to do brute-force attacks. It’s unfortunate that the version of fail2ban in Debian uses /tmp/fail2ban.sock for it’s Unix domain socket for talking to the server (the version in Unstable uses /var/run/fail2ban/fail2ban.sock). They also mention patching network drivers to add entropy to the kernel random number generator. One thing that seems interesting is the package randomsound (currently in Debian/Unstable) which takes ALSA sound input as a source of entropy, note that you don’t need to have any sound input device connected.

When considering fail2ban and similar things, it’s probably best to start by restricting the number of machines which can connect to your SSH server. Firstly if you put it on a non-default port then it’ll take some brute-force to find it. This will waste some of the attacker’s time and also make the less persistent attackers go elsewhere. One thing that I am considering is having a few unused ports configured such that any IP address which connects to them gets added to my NetFilter configuration - if you connect to such ports then you can’t connect to any other ports for a week (or until the list becomes too full). So if for example I had port N configured in such a manner and port N+100 used for ssh listening then it’s likely that someone who port-scans my server would be blocked before they even discovered the SSH server. Does anyone know of free software to do this?

The next thing to consider is which IP addresses may connect. If you were to allow all the IP addresses from all the major ISPs in your country to connect to your server then it would still be a small fraction of the IP address space. Sure attackers could use machines that they already cracked in your country to launch their attacks, but they would have to guess that you had such a defense in place, and even so it would be an inconvenience for them. You don’t necessarily need to have a perfect defense, you only need to make the effort to reward ratio be worse for attacking you than for attacking someone else. Note that I am not advocating taking a minimalist approach to security, merely noting that even a small increment in the strength of your defenses can make a significant difference to the risk you face.

Update: based on comments I’m now considering knockd to open ports on demand. The upstream site for knockd is here [8], and some documentation on setting it up in Debian is here [9]. The concept of knockd is that you make connections to a series of ports which act as a password for changing the firewall rules. An attacker who doesn’t know those port numbers won’t be able to connect. Of course anyone who can sniff your network will discover the ports soon enough, but I guess you can always login and change the port numbers once knockd has let you in.

Also thanks to Helmut for advice on ssh-keygen.

[1] http://www.debian.org/security/2008/dsa-1571

[2] http://blog.drinsama.de/erich/en/linux/2008051401-consequences-of-sslssh-weakness.html

[3] http://changelog.complete.org/posts/714-Thoughtfulness-on-the-OpenSSL-bug.html

[4] http://blog.sesse.net/blog/tech/2008-05-14-17-21_some_maths.html

[5] http://www.phrack.org/issues.html?id=11&issue=59

[6] http://www.enricozini.org/2008/tips/ssh-host-key-fingerprint.html

[7] http://www.docunext.com/blog/2008/05/14/my-security/

[8] http://www.zeroflux.org/cgi-bin/cvstrac.cgi/knock/wiki

[9] http://www.ducea.com/2006/07/05/how-to-safely-connect-from-anywhere-to-your-closed-linux-firewall/

Simon Richter: Solutions

Sun, 18 May 2008 02:22:54 +0000

(tl;dr: if you have a few minutes, please add information here)

Joss,

the problem with the new package formats is that there is nothing that actually uses the additional information in a way that adds significant new functionality, so the net result of the change was that we throw away the information at a different layer in our software stack, and one of the interfaces got a lot more complicated in the process.

One possible application would be a "poor man's patch tracking" inside the BTS, perhaps with a new state "fixed in patch".

I can see two ways of implementing that:

by extending the interface of the "new" package formats that {Debian,Ubuntu} bug numbers are attached to the actual patch files and having the archive maintenance software extract and process that information (reject packages that add a patch for a bug without closing it in the changelog, notify the BTS), or
by leaving the package format untouched and simply adding a regex matching "Fixes: #nnnnnn" that is reported to the BTS as "we have added a patch", so the submitter is notified that the bug is gone for him/her; the bug is then closed in the changelog of the upload removing the patch.

The former approach also allows us to link to patches from BTS pages, which the latter doesn't, so there could be actual benefit here if we believe it is worth the additional complexity.

(Update: Raphaël thinks it is. I like the idea of a package format with separate patches a lot more in this context than I did without it, but still my fear that it will actually be perceived as sanctioning large patchsets still remains.)

About mandatory co-maintenance: the problem isn't "helping". We have plenty of people with commit access to packages they don't even remotely understand who are really helpful (not). The problem is that someone needs to actually read all the commit logs and understand what the changes do in this context. In most cases, that person or group would be upstream, not a DD.

My first impression after reading the patch was "adding uninitialized data to the entropy pool is pointless/harmful as it is not random, so this patch makes sense", because the loop around it was not contained in the patch. Obviously I'm not an OpenSSL developer.

There is nothing Debian could have done internally to verify the correctness of this patch that would properly scale to the entire archive, even if we put "more emphasis on security". The only solution I see is reporting every patch to upstream immediately and getting affirmation that it is correct.

This, however means that we need to produce patches that upstream can accept. For obvious code bugs, that is simple, but for integration patches like paths it is not sufficient to replace one string with another, but rather make it configurable in some place that can be reached from debian/rules.

In an ideal world, we end up with very few Debian specific patches, so essentially we are talking about adding functionality to dpkg that we don't want to use.

I've started a page in the Debian Wiki, Getting Packaged with an outline of a possible document aimed at upstream developers that should list the typical problems we run into and how to avoid them.

Neil Williams: diff.gz stats

nospam@example.com (Neil Williams) — Sat, 17 May 2008 21:59:16 +0000

Romain, you might just want to check 471263 where there is disagreement over how this lintian test should or should not behave towards generated files. In particular, if a package contains a patch in debian/patches that causes upstream files to be modified indirectly (e.g. because upstream is old / quiet and hasn't updated the autotools stuff for years, any patch that affects Makefile.am or configure.in|ac is going to cause changes in generated files and these changes should not be wrapped into yet more patch files because of the inevitable build failures when any of the tools used to generate those files are updated.

Your stats may also be out because of this problem - it is hard to see how lintian can resolve the problem cleanly without carrying a long list of "possibly generated files" and risking the list going stale.

There is more to the contents of .diff.gz than may meet the eye.

Sune Vuorela: Comaintainers wanted

Sat, 17 May 2008 21:37:52 +0000

gnupg (1.4.6-3) unstable; urgency=low

* Adopt package. Thanks to James Troup for his work in the far past.
Thanks to NMU'ers Bastian and Thijs. (Closes: #476418)
* Co-maintainers wanted.
* Don't build-dep on pcap on non-linux-archs. (Closes: #357267)

-- Sune Vuorela Sat, 17 May 2008 15:42:55 +0200

TODO:

Coordinate with release-team and d-i what changes can still be done before lenny
Look at the new upstream version
Get a alioth project and host stuff in a version control system
Decide on version control system
Get a team and figure out team workflow
Look at this newfangled packaging thing called debhelper
Make all bugs either closed or forwarded

So - anyone interested?

Romain Francoise: Some .diff.gz statistics

noreply@blogger.com (Romain Francoise) — Sat, 17 May 2008 22:22:59 +0000

The OpenSSL fiasco has started a fresh discussion on Debian source packages and the way we handle changes to upstream software. One of the issues under discussion is that some Debian packages don't use a patch system and ship all their modifications unseparated in the Debian .diff.gz, which makes it harder or impossible to extract patches later on and to understand why some changes were made. The commonly recommended way of doing things is instead to keep the upstream source pristine, storing modifications cleanly separated and documented under debian/patches; several tools such as quilt or dpatch can make this process easy.

Out of curiosity, I did a quick scan of my local mirror to see how many packages ship changes outside debian/ in their .diff.gz, and I was surprised to see that 4803 source packages out of 11853 (40%) do so! This is much more than I expected. Some packages even use a patch system but still have changes in .diff.gz, as shown by this lintian check.

The most commonly patched files in affected packages are:

   1006 config.sub
   1002 config.guess
    823 Makefile
    754 configure
    715 Makefile.in
    484 aclocal.m4

Most of these are caused by autotools updates which are necessary if upstream ships old versions of these files. In many cases there are clean ways to deal with this, for example to always have up-to-date versions of config.{guess,sub} you can simply make them re-exec their authoritative versions (as shown by this patch) and build-depend on autotools-dev.

If you don't use a patch system, now is a good time to start. The New Maintainers' guide has more information on the topic.

Simon Richter: OLPC and Windows

Sat, 17 May 2008 21:14:48 +0000

There is an article on TechCrunch on Windows on the OLPC. This article started out as a comment below lots of comments that were missing the point, but eventually grew too large.

The entire discussion circles around the question whether it would be beneficial to give the users the same view and behaviour that is on 90% of machines worldwide, so they can start out prospective jobs with a minimum of training. Learning your way around the UI is only a significant part of training if that actual work you will do is trivial — so this argument basically boils down to "I don't expect the African kids to do anything but grunt work during their lifetime anyway, so we better start training them early", which is the wrong approach not only to education.

To make a bad car analogy, roads are usually made of several layers, from the foundation providing the stability up to the paint defining lanes. Operating systems are similarly layered, with a core that applications (cars) never touch directly, and several other layers on top of that that are not really required for basic functionality, but that add safety (process separation) or comfort (standard functions). The minimum standard of things is a "platform definition", which all car (or application) makers can expect — all roads have a minimum width and there are no dangerous spikes (if that is not true, you can get a steamroller or respectively format your harddisk).

Railways use the same kind of foundation (operating system), but the platform (heh) is quite different. You cannot drive a car on a railway, or a train on a road, just as you cannot run a Windows application on a Linux system or vice versa (there are special wagons you can place your car on, and special trucks with rails on them if you feel like it, but these are heavier and need more energy to pull).

Now in this discussion, people have been comparing Windows (the platform) to Linux (the operating system). That doesn't work.

On Linux, there are several platforms available, the most prominent being GNOME and KDE for the desktop and POSIX utilities on the command line, but there are lots of others as well. Part of most platform definitions is an user interface, which abstracts what is really happening to something comprehensible to the user, using analogies (a tachometer displays our speed as an angle usually, but other representations are possible).

The "desktop" idiom happened to be the first graphical UI some thirty years back, and was perpetuated into today's computers (just like the width of roads hasn't changed from the days of the Roman empire, where it was "two horses and then some"), however this doesn't mean it is the best choice available — it's just what we are used to.

If you look at the screen contents on the day traders' computers (lots of that on the TV right now thanks to the market crisis), you will notice the vast majority does not use overlapping windows or standardized "rising-edge" buttons to click on, but rather, they have a tightly-packed grid layout with high-contrast information displays that also color-code certain messages.

I think that is the most important point here: to achieve optimal results, the presentation idiom needs to be chosen in a task specific way.

With children as the target audience, we lose one of the key requirements behind the adoption of the windowed view: the need for side-by-side presentation of data from multiple unrelated sources (which is also a problem given the lack of screen space). With the introduction of ad-hoc mesh networking and collaborative applications, the "desktop" analogy begins to break down.

The project's mission also defines requirements on the platform. If we want to keep the requirement "users should be able to build and share their own stuff", then we want a framework where it is hard to make mistakes, especially those that can be spotted only after an interesting failure, and more importantly impossible to write code that makes unrelated components fail, because these components might be your way back out of the situation.

Windows has an excellent event model with fairly good isolation of components (to the point where a problem in an event handler can be handled by the event loop rather than terminating the program, so for example Internet Explorer can shut down broken plugins rather than crashing), but the detail knowledge required to really work with the API (how to build a message loop that also runs queued I/O completion handlers correctly) leads to a fairly steep learning curve, and would teach implementation details rather than concepts.

The normal "linuxy" approach of going low level whenever higher-level approaches fail is not the answer either as we want to truly empower people rather than just training them to be a cheap replacement for the tech support Indians (no offence), so it is vital that the "real" applications use the same framework that people implementing new things would use, and thus all the complexity that we want in our "official" applications needs to be taken care of by the platform, with all the safety features in place too.

So no existing platform provides what we want. — hence Sugar. And that is the problem for Windows advocates: Sugar replaces those bits that make Windows a platform and not just a kernel, so porting Sugar to Windows doesn't make sense from a technical point of view, since we already replaced the bits that we didn't have free software for before.

Other than that, the "Linux vs. Windows" kernel choice is secondary; in fact both kernels are very similar in design and function, the various advantages and disadvantages of either aren't that relevant really.

The only technical reason in favour of Linux is the virtual memory management — the Windows VMM behaves erratically in the absence of a swap device, but I believe that is not something that cannot be fixed.

The reason why I believe Linux is the better choice here is long-term support.

Since these devices will be used in basic education (which hasn't changed that much in the past years as 1 plus 1 still equals 2), there is hardly any need for radical changes after the initial rollout — why add instability when you don't have to? With Microsoft as a for-profit company, there needs to be a business model sustaining that behind it, and I believe it will be very hard to find one. "Subscription" falls down in that it is a long-term recurring expense, which governments tend to be pretty wary of.

The alternative is to upgrade several million computers' OS every few years. Lots of companies are skipping entire Windows releases because of the migration cost, and even with the "console bonus" (all hardware is the same) and bootloader support for software upgrades over a mesh network, this is still a massive endeavour. That each machine would have to reserve enough memory for the entire "upgrade pack" so it can transition "in one go" also makes this model unworkable.

To summarize, using Windows on the OLPC does not make sense at all. If you use just the kernel, you don't gain anything over Linux, and if you use the entire platform (and by extension, the UI), you add unnecessary complexity that is not only not required for the actual task, but also distracting. If you add restrictions and extensions to make it work, you invent a new platform, which is precisely what Sugar did.

The argument that it is important for pupils to use the same thing that the rest of the world is using to ease their entry into the workforce is bogus at best, and racist at worst.

Kartik Mistry: Inhumanity

Sat, 17 May 2008 20:36:09 +0000

* Somebody told that ‘This is inhuman‘. Now, please someone please preach similar to China!

Jeff Bailey: 3mo surgery update; Step-Grandmother-in-law; Almost back to work

Sat, 17 May 2008 20:25:10 +0000

Hey! I have my 3-month update with my surgeon on Tuesday. We'll be hopefully reviewing my movement restrictions and getting the final all-clear to return to work at the beginning of next month. I don't expect that I'll be able to lift Leif, but even if I can twist and bend a little bit and reach out with both my arms at once it would be a huge improvement for me.

Do any of you have any questions? I'm going to ask for some clarification on the photo that I posted before (and hopefully will get another one). But if there's anything that other people want to know, I'll ask as much as I can.

Yesterday my wife's (Angie) father's (Ernie) wife's (Janet) mother (Lydia) died from a heart attack. I've only met her a few times, so I'm not really shaken by it, but she was a really nice lady. Something I think about is that with Janet marrying into the family after Angie and her siblings had all moved out means that there's a large chunk of Leif's family now that Angie and I can't really teach him about. So, I worry about Henry, and I'm thinking a lot about Janet. Since we're going up to Vancouver at the end of the week, we should hopefully be in town for any memorial service.

It's crazy to think back over the past 3 months. Various family members health problems; Leif learning to walk, and getting his first words; Leif moving to his own room and his own bed; Going from where I needed a walker and a trip to the mailbox was far, to where a ~1km to a park pushing a stroller makes me tired, but I can do the trip back easily enough; Going through the work to change to a new work visa; almost completing one of my master's courses; and importantly: I've got 30 of the songs finished on "Hard" in Guitar Hero 2.

It'll be fun to get back to work and regular life, though. =)

Kartik Mistry: Meeting with Kstar and Weekend

Sat, 17 May 2008 19:50:19 +0000

* Mistake happens in Life. I did it too, you may have done it in the past. There is no point of digging grave. Probabaly time to do some work to make sure that it will not happen again.

XKCD Tribute.

* Kstar (Akarsh Simha, GSoC candidate of KDE Project, Kstars) is in city (I mean his hometown!) enjoying his vacation, so I decided to meet him on Friday. I wanted to do it on Saturday but some other plan was there which indeed never happen and that is another story itself. Anyway, we met near MG Road/Brigede Road junction and went to Pizza Hut. Nice disucssion of 2 hours, nice pizzas and finally mandatory click. We talked from Debian to FOSS culture in IITM (Note that IITM has 2 most active DDs from India!).

* So, my Saturday was totally wasted due to silly things. Dear Kushal was not there in town — so, none was there to annoy from me. I thought I was able to wash my all dirty clothes in the morning but, it was power cut! I waited till 12PM to bathe (Indeed, you can’t take bath without power as bathroom is too dark, and I fear cockroach too much).

Power went again around 6 PM and I went outside, wondered here and there, came back to home. Still no power. OMG, it came after 10.30 PM!

Yet another reason to hate this city, BLR.

Uwe Hermann: Green energy from Lichtblick getting... cheaper!

Sat, 17 May 2008 17:16:29 +0000

You might remember that I wrote a blog entry about my switch to the green electric utility "Lichblick" (Germany) a while ago. I did that purely out of environmental reasons, I didn't want to continue to waste money on polluting and/or dangerous crap such as fossil or nuclear power. Yes, even if that meant a slightly higher price (but I really didn't compare prices much before switching — I was after an environmentally clean solution, not the cheapest solution).

Quick status update: the switch went really nice and easy, no downtimes, no hassle. I've been a happy customer for more than 8 months now.

Today in my snail mail inbox: a letter from Lichtblick that they're going to reduce the price per kWh from 20.25 to 19.99 (Euro) cents starting July 1st and they give you a guarantee that there won't be any price raises before the end of 2009 (more details also here). Now, that's a positive surprise there.

Compare that to 98% of all other energy providers in Germany who have lately increased prices quite a lot for very obscure or non-existant reasons.

Yes, I do realize that the reduced costs are not that dramatic, and Lichtblick is using this as a means to impress people and gain new customers. But I fully support them in doing so, the more people are switching to a green energy provider the better, if you ask me. I encourage everyone to consider switching, either to Lichtblick, or some of their competitors (in Germany) e.g. Greenpeace energy, Elektrizitätswerke Schönau, or Naturstrom AG. There are various alternatives in other countries too, of course.

Enrico Zini: How to view the fingerprint of the ssh host key

Sat, 17 May 2008 12:38:13 +0000

How to view the fingerprint of the ssh host key

This way, ready to copy and paste:

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

Background:

It already takes a lot of resources to recall that to see the host key fingerprint you need to run something called 'keygen'. Then ssh-keygen doesn't support --help: it will try to generate a new key instead. We're in 2008. There should be a law against this sort of behaviour.

To figure out how to see the host key, you need to dig through a long manpage with no examples section. ssh-keygen does have commandline help, but does not implement any switch to invoke it (check the getopt invocation in the source code if you don't believe me). It will however show commandline help when given an unrecognised option, so it will mutter but at least give you love if you ask for it:

$ ssh-keygen -♥
ssh-keygen: illegal option -- 
Usage: ssh-keygen [options]
Options:
  [...]

After figuring out that it's -l -f, you still have to go and fish the file wherever it is. And luckily we had the recent Debian openssh problems, so now I can get the fingerprint of the RSA file only and be done with it.

But thanks to this blog entry, no more of that, at last.

Joachim Breitner: FrakView: An Haskell Renderer for Iterated Function Systems

mail@joachim-breitner.de (nomeata) — Sat, 17 May 2008 12:31:10 +0000

For a recent university seminar, I wrote a haskell program to render and edit iterated function systems (IFS), which generates a certain class of fractals, namely self-similar sets. I think the result is quite nice, so I’m sharing the code.

With FrakView you can view a rendering of the attraktor of the IFS, whith a choice of two algorithms (a straight forward, and a probabilistic), configurable depth and anti-aliasing. You can also modify the IFS by dragging the colored boxes with arrows you see on the screenshot. For the academically inclined, there is also support to visualize cylinder sets and otherwise explore the coding space of the IFS a bit.

The program is written in haskell and uses gtk2hs, the gtk bindings for haskell. It might be interesting for other gtk2hs programmers to see how FrakView solves some issues: For example, it uses the CoroutineT monad transformer I recently blogged about – check out the pausingForM_ function in GUI.hs. Also, the current state of the screen is in one algebraic data type (ScreenConfig) that supports equality checks, so when the user interacts, the code recomputes the new ScreenConfig (using getRenderer), but only redraws the screen if it differs from the previous. This is much easier and more robust than having to decide for each possible user interaction whether it changes what’s on the screen.

You can get the source from the FrakView darcs repository.

Kai Hendry: Regenerate your .ssh/id_rsa key Debian users

Sat, 17 May 2008 12:05:41 +0000

Whoa, this security bug exposed by Luciano Bello (Ola!) is one of the worst I’ve ever seen.

Time to regenerate your key with the updated openssl 0.9.8c packages.

~~This seems to be Debian specific patch that caused this bug.~~

Further instructions should be posted on a special Debian key rollover page and the Debian wiki.

Update: key rollover is hard. :/ `ssh-vulnkey` was missing for awhile and only recent updates to openssh-server seem to regenerate the keys for me.

Josselin Mouette: Some lessons to learn

Sat, 17 May 2008 12:04:19 +0000

There are obviously some things we need to remind if we don’t want something like the OpenSSL debacle to happen again. It doesn’t mean we need to throw stones nor to rush into changing our processes without thinking. However, there are already some things that should be obvious but unfortunately are not.

Shipping a giant diff.gz that contains all changes in one, putting security fixes, policy fixes, bug fixes, cosmetic changes and autotools files at the same level, is not something we should accept anymore. Improvements in the dpkg-source format are much welcome in this direction, but they are useless if maintainers don’t use them. Neither a VCS nor a build tool will be able to know which line of the changes is related to which bug. Only the maintainer can.
Core packages should all have co-maintainers. This is pretty much stating the obvious, and is much easier said than done. The OpenSSL case is one of the best examples here: Kurt is not one of those who refuses help, but frankly, would you want to maintain that package? Having already maintained packages with messy code, upstreams not understanding at all the needs of a distributor, avalanches of security alerts and randomly-changing ABIs, I can tell you this is no fun like it can be to hack on a desktop environment or a device driver. The only sane reason to do this is that you need the package to work. The only visible result you get from your work is that programs are not randomly crashing.
I have no magic recipe to propose so that more people help with such packages, and that’s where we need to be really innovative. Cross-distribution teams, mandatory co-maintainership on a core package for each DD… these (and all ideas I have not heard of) are the experiments we should start now.
Patching bad code leads to unpredictable results. What maintainer of a complex package has not introduced a new bug while trying to fix another one? Even when a piece of code is maintained by uncooperative developers, is not commented, uses arcane variable names or is impossible to understand without having contributed 3 winning entries to the IOCCC, it needs to evolve. And in these cases, it is only a matter of time until such things happen.
Don’t get me wrong: I’m not trying to put the blame on upstream here. They have contributed very valuable code to the community and their work helped in the considerable widespread of cryptography. It’s just that their code is not enough for our needs. If we can’t patch it safely (and I’m now convinced we can’t), maybe we need to focus on alternatives and help them getting used by crypto-related packages. The code in GnuTLS and NSS is not necessarily better, but most (if not all) patches Debian needs to apply to them are build and portability fixes.
Unless Debian-specific, 1 patch = 1 bug in the upstream tracker. This should be obvious, but given the number of patches that are never forwarded, it doesn’t seem so. You should not only give a chance for upstreams to review the patch, but you need them to track it, and you must give them the chance to review it anytime someone else stomps on a similar issue. If upstream does not have a bug tracker, they probably think their software has no bugs. Which means they are not trustworthy, and we go back to point 3.
We need to give more priority to security. Issues in the security team seem now fixed for good and they have been doing an awesome work. There isn’t much left to do so that packages are all built with security-hardening features, but it still needs to be done. And there is much more to do so that we can provide out of the box a decent SELinux setup, or, if it turns out unrealistic to do, a decent system hardening setup using another framework. I know the SELinux zealots will jump on their high horses to explain that their framework is better, but the current situation where it is impossible for the average system engineer to setup a Debian-based MAC system is much worse than having a suboptimal setup that already works.

All in all, this incident has a great impact on Debian’s image. If we don’t react accordingly, adapting our processes and our system to match what our users expect from us – and they expect the best – they will turn away from us. With very good reasons to do so.

Update : It seems OpenSSL does have a bug tracker. Thanks Kurt for pointing me to it.

Adeodato Simó: Going to movies, heh, literally alone

Sat, 17 May 2008 11:58:47 +0000

So going alone to the cinema yesterday was not a first, but going alone and being alone in the room certainly was, and an unexpected one.

This was, as far as I know, the premiere in Alicante of Enloquecidas, which is certainly not that of a remarkable film, but which was entertaining enough, and provided some very good laughs.

What is wrong with this city?!

(Update: hm, seems I’m mistaken about the “premiere” bit. Oh well.)

Andrew Pollock: [life] More on flying British Airways

Sat, 17 May 2008 11:45:00 +0000

Heh, in the 11 or so hours since my last blog post I've received two emails from people going "yeah BA is crap!"

Well the flight itself was fine. The plane was nice. The entertainment system was pretty decent. The UI was all touch screen based, which made it less clunky than Qantas'. Food-wise, I thought the dinner tray was pretty loaded with stuff.

Only problem is that the flight was running about 10 minutes behind schedule, then had to hang around in the air at Heathrow for about 10-15 minutes, so we didn't make our connecting flight. BA bumped us to the next one without any problems, so now we're chilling out in the spiffy new terminal 5 BA lounge for an hour. I guess an hour just doesn't have enough fat in it for a connection.

Terminal 5 is pretty shiny in general. Hopefully our bags won't get lost.

Patrick Winnertz: cowdancer in unstable - no longer support for stable release?!

Sat, 17 May 2008 10:40:52 +0000

Cowdancer is activly developed in debian, that's very nice. it's really a cool tool to build packages for unstable but also for backporting efforts. I'm using it on a daily basis to build debian etch packages of lustre. However three days ago cowdancer stopped working with my etch chroot after an upgrade of my unstable system:

dpkg-source: info: building lustre in lustre_1.6.5~rc3-1.dsc
dpkg-genchanges -S >../lustre_1.6.5~rc3-1_source.changes
dpkg-genchanges: including full source code in upload
dpkg-buildpackage: source only upload (original source is included)
chroot: cannot run command `cowdancer-ilistcreate': No such file or directory
W: cowdancer-ilistcreate failed to run within chroot, falling back to old method
 -> Running in no-targz mode
I: using fakeroot in build.
Current time: Sat May 17 12:18:30 CEST 2008
pbuilder-time-stamp: 1211019510
 -> copying local configuration
 -> mounting /proc filesystem
 -> mounting /dev/pts filesystem
 -> policy-rc.d already exists
Obtaining the cached apt archive contents
Installing the build-deps
cowdancer: .ilist size unexpected
cowdancer: .ilist size unexpected
Can't open perl script "/usr/bin/dpkg-architecture": Cannot allocate memory
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
cowdancer: .ilist size unexpected
cowdancer: .ilist size unexpected
cowdancer: .ilist size unexpected
cowdancer: .ilist size unexpected
cowdancer: .ilist size unexpected
sh: /tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy/DEBIAN/control: Cannot allocate memory
E: pbuilder-satisfydepends failed.
Copying back the cached apt archive contents
 -> unmounting dev/pts filesystem
 -> unmounting proc filesystem
 -> Copying COW directory
 -> Invoking pbuilder
 -> Cleaning COW directory
Command /bin/sh -c pdebuild "--pbuilder" "cowbuilder" "--" "--basepath" "/var/cache/pbuilder/etch.cow" failed

After some research I found that a change of cowdancer (something related to .ilist) is responible for this issue. After that I asked on #debian-devel if someone else had this problem and were told that removing an re-creating the chroot will help. But that results in the same error msg. After that I decided to wrote a bugreport against cowdancer, since this is in my eyes a major defect in this software to do not support the latest stable release. I filled this report as RC Bug and got very fast a answer:

severity 481344 wishlist
retitle 481344  provide cowdancer etch backport
[ ... ]

I think this is the wrong way to fix a problem in unstable with a backport of a software. Providing a fallback for older debian releases would be the better way. Is anybody else having this problems?

Clint Adams: It was GORGEous and GOLDEN until it was black

Sat, 17 May 2008 03:36:36 +0000

[This entry is dedicated to Russell, ﷺ, and the squirrels (صلى الله عليهم وسلم) that tried to sit on my lap even though I told them that I was not toresbe.]

The man handed us burritos full of spinach-infused E. coli and salsa verde of the botulist manifesto. Para llevar? You bet. I need to get me some waterfall Giardia to right my viscera or I'm bound to start hallucinating mountain paths full of dogs, Россиянe, inedible gorp, and children throwing themselves to their death. Hi, kids.

池乃花, 納豆, ミルクイ, what happened to the garlic bread‽ Can you imagine being allergic to 艾絨? My Dreamsicle can't.

Now fly, fly away to the land of the peppermint tea, the deer without fear, the queer, the other beer, Sue's sambar. I like my இட்லி pretty damn fancy, but we're not in मुंबई, are we, Toto?

There is a warp in the space-time continuum, causing multiple instances of calderae and 27 Dresses. One fled a bookstore and flew to its adopted homeland. One time.

It sure is windy atop this peak, and while Phil Collins sings about burning down some kind of mission, the husband is eying Mr. MacLachlan. My ex's ex gives a lesson about testosterone, but we are too far away to see the bison. The bison do not, it would seem, give a damn about us or Irving, and they do not care about the worker exposing her VS panties.

A secret hidden jeep whisks, and a card hides defiantly in my wallet. Nothing more can be said, and not for the reasons you think.

Kai Hendry: VIM IDE for Web applications

Sat, 17 May 2008 02:09:10 +0000

To follow this little screencast tutorial on editing Web applications:

apt-get install vim curl subversion on a Debian install
Letterly source I use for an example
.vimrc see CleverTab()
HTML5 VIM script for validator.nu

Recorded with recordmydesktop—follow-mouse -width 256 -height 256. I had to record it on my Thinkpad X40 as my X61 sound setup suffers from some sort of overrun. Couldn’t figure out jackd.

Validator.nu is for helping find problems with HTML not PHP, so sorry for the sideline 2:30 mins in the video. :) Finally also “checkout” Google doctype.

Daniel Stone: faq: dsa keys

Sat, 17 May 2008 00:20:28 +0000

A quick FAQ: the reason all DSA keys have been removed from fd.o and we aren't accepting any new ones is that they are vulnerable to man-in-the-middle attacks if they have ever been used (not just generated) on a system with a predictable RNG: see Steinar's summary of the maths. We're going with precedent of debian.org rejecting DSA keys, and a general desire to be safe rather than sorry. RSA keys are the default in OpenSSH anyway, so I'm not really sure why you'd want to generate DSA.

Andrew Pollock: [life] On flying British Airways

Fri, 16 May 2008 22:19:00 +0000

(Well we haven't even gotten on the plane yet)

I'm pretty sure that this is the first time I've flown British Airways.

Sarah and I are off to Zurich via London, and when we rocked up at the airport to check in, we couldn't get seats together. We're sitting in the middle seat in front of each other.

We were quite taken aback by this, as we've done a fair bit of flying together and never had this happen before. We mentioned this to the customer service person when we dropped our bags off, and she told us the reason was because they have online check-ins, all the seats go from people checking in online. They only seat people together with infants, in parties of three, or in a wheelchair. She went on to say all the airlines are like that.

Not in our experience.

So once we got through security and into the BA lounge, I thought I'd try again and see if we could get reseated. The customer service person in the lounge had a quick glance at the computer, and told me there was nothing available. There was no attempt to re-seat other passengers travelling alone, or anything. It looked like she based her inability to do it off the available seats.

I'm just really surprised.

Jonathan McDowell: I'm totally Rick Moranis

Fri, 16 May 2008 19:53:34 +0000

I mentioned on my switch to Movable Type post that there were a few things that were hopefully going to happen RSN and that I'd talk about them if they did.

Well, one of them did, and Steve helpfully dropped me in it earlier in the week - I was granted write access to the debian-keyring. It's worth pointing out that while Steve did some prodding around this the process started quite some time ago; back in November James Troup (the other current keyring maintainer, and at the time the only one) contacted me regarding an offer I'd made to help out in whatever way I could. As a result I got involved in the keyring RT queue and did some basic triage and trying to point people in the right direction, where such help didn't require any keyring privileges. I also started thinking about how keyring maintenance could be shared in a trackable fashion. I made some suggestions to James and he was largely in favour with a few suggestions and wishlists.

I'll get into discussing exactly how it goes at a later point in time, but for the moment I want to get a better feel for the process and procedures to fine tune things. To that end I've been working my way through the keyring RT queue, and have removed quite a few keys of retired developers, as well as doing a handful of replacements for developers who'd lost or had their key compromised. There's still a few more tickets in progress and I'm trying my best to work through them in a timely manner - if you have an outstanding ticket and haven't heard from me then please do feel to ping it.

Adeodato Simó: Going to movies alone

Fri, 16 May 2008 18:55:08 +0000

Unlike Steve, I don’t particularly mind going to the cinema alone. In fact, it’s becoming a growing habit for Friday nights, when my friends go to some meetings about their faith I don’t participate in (nor their meetings, nor their faith). I really hate getting home early on Fridays, so I take chance to go to movies I know we wouldn’t be going together anyway.

(Oh, and in case I haven’t said here already, the movie offerings in this “city” suck big balls. Virtually no undubbed sessions, virtually no non-mainstream movies. I don’t think I’ll still be here in a couple years, but boy would I be unhappy if the circumstances forced me to.)

Adeodato Simó: Disregarding warnings

Fri, 16 May 2008 18:20:14 +0000

Here in this library, next to a couple computers available to query the catalog, a sign reads:

Do not connect your laptop to these jacks. You may loose all data in your computer.

If I wasn’t a computer-savy person, I’m completely sure I would’ve thought: “They’re bluffing.” And then shit happens, because they’re not.

(Oh, but then of course the sign is not 100% honest either.)

Romain Francoise: This is not a psychotic rant

noreply@blogger.com (Romain Francoise) — Fri, 16 May 2008 18:17:59 +0000

For a split second, in the opening shot of “The Peanut Reaction”, I had the impression that Rajesh's laptop was running some sort of GNOME desktop, but it soon becomes apparent that it's actually running Mac OS X. Sheesh. When is Linux going to become mainstream?

MJ Ray: BBC TV: Click: Free=beer and facebook-flaming

Fri, 16 May 2008 17:15:36 +0000

Free software finally gets significant coverage on BBC TV's Click show this week, but I think it's very much Linux rather than GNU/Linux and free cost rather than freedom. They mentioned free security software and even raised the possibility of trojans, but didn't mention how free (as in freedom) software allows any random end-user to check or have it checked.

Quite a missed opportunity! However, Click has a regular letters section, so watch it (times below), email click@bbc.co.uk and see if we can get the free software view across.

The letters section this week seemed to be flaming proprietary SaaS social network site facebook for their pathetic default-permit approach to security of user details. I really think there's a role for something like noserub in free software social networking.

Click-UK is shown on BBC News Channel Saturday 1130, Sunday 0430 and 1130, Monday 0030 and Sunday 0430 on BBC-1 (times BST)

Click-World is shown Thursday 19:30 GMT, Repeated Friday 09:30 and 12:30 (Asia Pacific only), Saturdays 06:30, Mondays 15:30, Tuesdays 01:30 (not Asia Pacific, Middle East or South Asia) and 07:30 GMT

Anyone else see this?

Aigars Mahinovs: Fastforward to January 21st 2009

Fri, 16 May 2008 16:18:48 +0000

“… Today is the first day in office for President Barack Obama … In other news, Hillary Clinton is still on the campaign trail and is not giving up …” - best ever joke about the current US election. I think it was from The Daily Show, but I cannot be certain.

Ondřej Čertík: FOSSCamp, Friday

noreply@blogger.com (Ondřej Čertík) — Fri, 16 May 2008 17:17:02 +0000

Since I live in Prague, it's basically compulsory to go to FOSSCamp. Yesterday I went with Lucas to some pubs + sightseeing, today we went in a larger group to this pub:

and we had a couple of good Czech meals with Plzeň beer:

Seems it tasted good:

Chris Lawrence: Things that are icky about R

Fri, 16 May 2008 15:57:35 +0000

Andrew Gelman notes that the default graphics functions suck and that R has no real idea that all numbers aren’t conceptually signed floats. Gelman is told that the default graphics functions aren’t the ones we’re supposed to use these days (e.g. Trellis graphics a.k.a. lattice and a bunch of stuff I’ve never heard of before today is preferable) and that R does have some idea that all numbers aren’t floats, but you have to convince R that the numbers you have aren’t floats, or something.

I think Gelman wins the argument by default.

David Welton: Neat Hecl app from newcomer

Fri, 16 May 2008 15:47:00 +0000

This is a cool little application, and a helpful tutorial for people trying Hecl for the first time. Since I know the system so intimately, people doing these kinds of pages are always a helpful reality check, pointing out where people new to the language hit stumbling blocks, and providing a guide for people who haven't "been there and done that":

http://lauri.ojansivu.googlepages.com/heclcommandlineapp

Thanks Lauri!

Daniel Leidert: /usr/lib/python2.3 garbage

Fri, 16 May 2008 15:40:39 +0000

Yesterday I stumbled about files and dead symlinks left in /usr/lib/python2.3/site-packages/ on my Sid box. These files/symlinks seem to have been shipped/created(?) by:

python-ldap python-cairo python-crypto kiki python-foomatic python-mysqldb
python-logilab-common python-egenix-mxtools python-numarray python-pygresql
python-imaging-sane python-imaging python-xml python-reportlab

Deleting /usr/lib/python2.3 (dpkg -S didn’t show any package relationship nor did I find something in /var/lib/dpkg/info/) and reinstalling the above mentioned packages did not recreate the files/symlinks. So it seems the directory can be safely removed. Maybe I missed some announcement or one (or more) packages need to be fixed. No time to examine it atm.

Update

This is known as Debian bug #409390. Thanks to Josselin Mouette for the information.

Joey Hess: fiber installation

Fri, 16 May 2008 15:14:03 +0000

I was reading about fiber to the home, but got interrupted by the fiber installation man.

BTES got here less than 24 hours after I signed up, so I got to see a fiber optic splice done in the field this morning, 1st time for me.

I think they're using Active Ethernet. I will so not miss my crappy cable modem.

James Morrison: Random thought

noreply@blogger.com (Jim) — Fri, 16 May 2008 16:01:58 +0000

So qwerty was designed to avoid having two keys beside each other typed in a row. This was to avoid jamming keyboards. Dvorak decided this wasn't a useful design goal, so made his own keyboard. Anyway, this criteria to avoid jamming also makes qwerty better for small keyboards, since the jamming is now done between my fingers instead of the keys on a typewriter.

Kapil Paranjape: Computers and I

Fri, 16 May 2008 14:58:00 +0000

This post is to some extent a fall-out of the recent discovery of a serious flaw in Debian's openssl and openssh packages. However, as Raghavan will confirm, a weaker version of what is said below was part of our discussion two weeks ago. Moreover, there are earlier posts on this topic in this blog.

There are times when I wonder why I am so involved with computers ... this is clearly one of those times.

कर्मण्यैवाधिकरस्ते मा फलेशु कदाचन
karmaNyaivaadhikaraste maa faleshu kadaachana

This is a phrase from the भगवद गीत (bhagavad giit) which has been stuck in my head for the last 30 odd years. It roughly paraphrases into

Do something because you think it is worth doing not because of what you hope to achieve by doing it.¹

The above maxim is a good one but is sometimes a cop-out. Moreover, it provides no basis for actually making ethical choices.

Ethics comes from one's interactions with the communities one is a part of. There are (roughly) two communities that I am a part of in the context of computers:

the FOSS community; specifically, the Debian community.
the IMSc computer community

I take these in turn below.

Debian and FOSS communities

By its own standards, the Debian community has suffered a massive failure ... and by these same standards it has reacted extremely well to this failure.

I feel shame and blame. Why have I been ignoring RFH#332498 all these days when it shows up in the output of wnpp-alert? Here I am, a mathematician with some understanding of the issues, not helping out! Three years ago I even gave a short course of lectures on implementations of crypto; the source of openssl and openssh were used as examples. Excuses like, "I don't know anything about library packaging" and "I need more time!" (who doesn't) seem too weak now.

At the same time, I feel a sense of solidarity with the Debian (and more widely FOSS) community as it tries to pull out of the resulting mess. The resilience that allows us to laugh wryly at ourselves is IMHO admirable.

As Steve Kemp wrote: "[When we look back we will see that] we did good".

IMSc computer community

The IMSc computer setup was built by volunteers and was genuinely a community when I joined this institute in 1996. It has since then broken into users, system administrators and the computer committee. As Indira Gandhi would have said: "This is a world-wide phenomenon", and as was the case when she said it, my response is: "That doesn't make it a good thing!"

When I speak about this fractured IMSc community below it is in generalities. There are certainly individuals who rise above the shards.

I have been promoting the use of FOSS and more specifically Debian at IMSc ever since I got here. While explaining the pragmatic aspects like cost and security, I have also tried to emphasize the freedom and community aspects of FOSS use. When the latter are not understood or accepted, the former are easily blown away.

This year I made an attempt to get the Computer Committee to invite users to choose² their own computers and the software that ran on it, but it turned out that no one really wanted this. Users just wanted to buy "fancy toys", the administrators just wanted to make their life simple and CC members just wanted the power to dictate what people bought.³

I also made an attempt to get our users to educate each other on the use of computers for their work --- first through the establishment of a wiki and then through the "No-Excuse" mailing list.⁴

Unfortunately, the fractured IMSc computer community sees computers and software as expensive commodities --- with some combination of fear, greed and irritation. In any case, there is no feeling of being part of a larger community that is trying to solve (certain types of) problems.

A wise man once said:

With great freedom comes even greater responsibility.

This may explain why we prefer being dictated to by proprietary vendors and computer committees that "buy stuff for us". We are afraid of the responsibility that comes with freedom.

Another much quoted quote is:

If you are not part of the solution then you are part of the problem.

The FOSS community (actively) invites people to join-in in solving problems. This participation (which can be at a level of one's own choosing) is the source of one's freedom in free software. The IMSc community just wants मा-बाप सर्कार (maa-baap sarkaar) to fix their toys.

A decision

The IMSc computer community was tied to Debian and FOSS after the break-ins into our system in the early 2000's. At that point, I was instrumental in installing a security infrastructure based mainly on Debian. This led to my greater involvement with FOSS and Debian and also to the greater "infiltration" of Debian and FOSS into IMSc computers.

From the "commodity" point of view at IMSc we have come a full circle since most users will have to "do a lot" so that the IMSc computer LAN emerges unscathed from the crisis created by the Debian openssl flaw.

From the "community" point of view at Debian we have spiralled out and even this major whirlpool will not drag us back in.

It is no longer possible (for me) to straddle the circle and the spiral in an attempt to widen the former; I'm taking the "outward radial vector"!

To this sentiment I have often added "do it because it's fun". ↩
... and be willing to justify their choices of course.[WGFCEGR] ↩
OK! I'm exaggerating a bit! ↩
No-Excuse is an acronym for Novice and Expert Computer Users. The blurb says:
Now that this list exists there is "no-excuse" for novices to remain in-experienced or for experienced users to claim that something is "too hard to explain to a novice"!
↩

Russell Coker: Ideas to Copy from Red Hat

Fri, 16 May 2008 12:54:06 +0000

I believe that the Red Hat process which has Fedora for home users (with a rapid release cycle and new versions of software but support for only about one year) and Enterprise Linux (with a ~18 month release cycle, seven years of support, and not always having the latest versions) gives significant benefits for the users.

The longer freeze times of Enterprise Linux (AKA RHEL) mean that it often has older versions of software than a Fedora release occurring at about the same time. In practice the only time I ever notice users complaining about this is in terms of OpenOffice (which is always being updated for compatability with the latest MS changes). As an aside, a version of RHEL or CentOS with a back-port of the latest OpenOffice would probably get a lot of interest.

RHEL also has a significantly smaller package set than Fedora, there is a lot of software out there that you wouldn’t want to support for seven years, a lot of software that you might want to support if you had more resources, and plenty of software that is not really of interest to enterprise customers (EG games).

Now there are some down-sides to the Red Hat plan. The way that they run Fedora is to have new releases of software instead of back-porting fixes. This means that bugs can be fixed with less effort (simply compiling a new version is a lot less effort than back-porting a fix), and that newer versions of the upstream code get tested. With some things this isn’t a problem, but in the past I have had problems with the Fedora kernel. One example was when I upgraded the kernel on a bunch of remote Fedora machines only to find that the new kernel didn’t support the network card, so I had to talk the users through selecting the older kernel at the GRUB menu (this caused pain and down-time). A problem with RHEL (which I see regularly on the CentOS machines I run) is that it doesn’t have the community support that Fedora does, and therefore finding binary packages for RHEL can be difficult - and often the packages are outdated.

I believe that in Debian we could provide benefits for some of our users by copying some ideas from Red Hat. There is currently some work in progress on releasing packages that are half-way between Etch and Lenny (Etch is the current release, Lenny will be the next one). The term Etch and a half refers to the work to make Etch run on newer hardware [1]. It’s a good project, but I don’t think that it goes far enough. It certainly won’t fulfill the requirements of people who want something like Fedora.

I think that if we had half-way releases of Debian (essentially taking a snap-shot of Testing and then fixing the worst of the bugs) then we could accommodate user demand for newer versions (making available a release which is on average half as old). Users who want really solid systems would run the full releases (which have more testing pre-release and more attention paid to bug fixes), but users who need the new features could run a half-way release. Currently there are people working on providing security support for Testing so that people who need the more recent versions of software can use Testing, I believe that making a half-way release would provide better benefits to most users while also possibly taking less resources from the developers. This would not preclude the current “Etch and a half” work of back-porting drivers, in the Red Hat model such driver back-ports are done in the first few years of RHEL support. If we were to really follow Red Hat in this regard the “Etch and a half” work would operate in tandem with similar work for Sarge (version 3.1 of Debian which was released in 2005)!

In summary, the Red Hat approach is to have Fedora releases aimed at every 6 months, but in practice coming out every 9 months or so and to have Enterprise Linux releases aimed at every year, but in practice coming out every 18 months. This means among other things that there can be some uncertainty as to the release order of future Fedora and RHEL releases.

I believe that a good option for Debian would be to have alternate “Enterprise” (for want of a better word) and half-way releases (comparable to RHEL and Fedora). The Enterprise releases could be frozen in coordination with Red Hat, Ubuntu, and other distributions (Mark Shuttleworth now refers to this as being a “pulse” in the free software community [], while the half-way releases would come out either when it’s about half-way between releases, or when there is a significant set of updates that would encourage users to switch.

One of the many benefits to having synchronised releases is that if the work in back-porting support for new hardware lagged in Debian then users would have a reasonable chance of taking the code from CentOS. If nothing else I think that making kernels from other distributions available for easy install is a good thing. There is a wide combination of kernel patches that may be selected by distribution maintainers, and sometimes choices have to be made between mutually exclusive options. If the Debian kernel doesn’t work best for a user then it would be good to provide them with a kernel compiled from the RHEL kernel source package and possibly other kernels.

Mark also makes the interesting suggestion of having different waves of code freeze, the first for the kernel, GCC, and glibc, and possibly server programs such as Apache. The second for major applications and desktop environments. The third for distributions. One implication of this is that not all distributions will follow the second wave. If a distribution follows the kernel, GCC, and glibc wave but not the applications wave it will still save some significant amounts of effort for the users. It will mean that the distributions in question will all have the same hardware support and kernel features, and that they will be able to run each others’ applications (except when the applications in question use system libraries from later waves). Also let’s not forget the possibility of running a kernel from distribution A on distribution B, it’s something I’ve done on many occasions, but it does rely on the kernels in question being reasonably similar in terms of features.

[1] http://wiki.debian.org/EtchAndAHalf

[2] http://www.markshuttleworth.com/archives/150

loldebian - Can I has a RC bug?: You can never be sure

Fri, 16 May 2008 09:03:18 +0000

MJ Ray: No Battles - Just Stand Firm On Best Practice

Fri, 16 May 2008 08:52:52 +0000

"Here are three examples of rules that I think it's time to abandon. These particular examples are all about email.
1/ Top Posting [...]
2/ HTML Email [...]
3/ Reply-To On Mailing Lists [...]
So, yes, the barbarians are at the gate. The lunatics have taken over the asylum. Good ideas have been crushed by the number of people who don't understand them. But there's no point in complaining about it. You just have to accept it and move on."

-- Pointless Battles For Geeks, By Dave Cross

Unsurprisingly, given the above links to my site, I disagree with Dave Cross's conclusion, but I do agree with two aspects: battling is generally pointless and using hard rules about these things is unnecessary.

I have those pages on my website so that I can point to them when their broken emails aren't handled as expected. I use some aspects of them as scoring inputs in my mail filters. I don't use them as rules and I try not to complain about them too often.

Nevertheless, I still believe sending properly-trimmed plain text emails from a list-friendly email client is clearly best practice, to be recommended when someone asks why their email bad habits are causing them problems.

Andrew Pollock: [life] Hottest May 15 on record

Fri, 16 May 2008 06:42:00 +0000

It's stinking hot. Right now, at nearly midnight, it's 22.9°C downstairs in the living room with the air conditioning on, and 32.5°C upstairs in the bedroom, with the window open.

No prize for guessing where we're sleeping tonight.

Jeff Bailey: Gay-Marriage in California

Fri, 16 May 2008 06:34:41 +0000

One of the proudest moments I had as a Canadian was sitting in the Senate visitor's gallery watching the debates on same-sex marriage that led to the full legalisation in Canada. In coming down to the US for work, I was sad to come to a place that not only didn't allow it, but had actually had a number of ballots in states voting specifically that the marriage referred to "One Man, One Woman".

I found a transcription of the Hansard of Prime Minister Paul Martin's introduction of Bill C-38 (The Civil Marriage Act). The logic in there for why Canada needed to legalise same-sex marriage is quite specific to Canada, but he talks about why it's important for the issue not to come to a vote:

The Charter was enshrined to ensure that the rights of minorities are not subjected, are never subjected, to the will of the majority. The rights of Canadians who belong to a minority group must always be protected by virtue of their status as citizens, regardless of their numbers. These rights must never be left vulnerable to the impulses of the majority.

I don't really understand the US system of rights. I hope that the protection of the right to love another consenting adult and make a commitment to them becomes the law of the land throughout the United States.

I love being married. I get the joy of being able to come home to my belle and share my day, spend time, and know that to the best of our ability, we're going to try to grow old together. I'm so happy that this ruling has come down and that in California the debate is now over.

Joey Hess: rtorrent: software for hunter/gatherers

Fri, 16 May 2008 05:45:55 +0000

There's something about certian very visually information dense console apps that makes certian bits of my neural network that have been quietly developing for years very happy. rtorrent is the best example of this ever (excluding the unix shell as a whole). It starts out a utter incomprehensible mess, and I can just feel my brain reconfiguring over several hours so it can understand it at a glance.

                 Chunks seen: [C/A/D 39/10/2.98]   X downloaded  X missing  X qu
Peer list          0 7465767364 6546566456 7576655464 3676833757 5654376467
                  50 5565765774 4785647665 4565464565 5777557464 4865465737
Info             100 4435567665 4547636475 6756567736 5665345373 6356566756
                 150 5454855548 6766756846 4476585655 5566676764 5665754652
File list        200 3674466375 7474666747 8766756866 5646667647 6677676353
                 250 5557754755 6755756775 4476686458 6544656687 5777557555
Tracker list     300 5567666653 7675564686 6263555577 6467766443 8635577643
                 350 7586655656 7765373543 4454677664 6654665666 4344666556
Chunks seen      400 6565665554 7656544673 7636765776 3567556727 6466735257
                 450 6344246566 7364539664 5366744446 6577564574 3563656833
Transfer list    500 5765366475 6685663564 7466756575 5567636754 4425467555

This is the same part of my brain that is happy out in the woods following along faint game trails. It's a pity that we've been taught to think of this kind of UI as "hard" and thus "bad".

                 12.xxx.75.xx    0.3    0.0    10.2   l/ci/ci  0/0    21Azureus
                 67.xxx.58.xxx   0.0    0.0    0.0    l/cn/ci  0/0   100uTorrent
               * 67.xxx.222.xxx  0.0    0.1    214.2  r/Ui/ci  0/2    88   617Az
                 24.xxx.89.xx    0.2    0.1    26.5   R/Ui/ui  0/2    30   695uT
                 65.xx.113.xxx   0.0    0.0    0.0    l/cn/ci  0/0   100Azureus
                 24.xxx.38.xxx   0.0    0.0    0.0    L/cn/ci  0/0   100Azureus

Does this make your neural networks light up and say "more plz"?

                 Transfer list: [Size 13]
Peer list        620 [P: 2 F: 0]AAAAaAAAAbbBBBbbbbaC...DdCc.....
                  59 [P: 2 F: 0]EEEEEeeFff......................
Info             141 [P: 2 F: 0]GGGGGGGGgGGg.GG.................
                 618 [P: 2 F: 0]HHHHHHHHHHHHHHHHHHHHHhhhh.......
File list        696 [P: 2 F: 0]IIIIIIIIIIIIIIIIIIIIIJJIIIIIijjI
                  26 [P: 2 F: 0]VVii............................
Tracker list      56 [P: 2 F: 0]WWWWWWWWWWWWWWWWWWWWWWWWWIWwIwIw
                  93 [P: 2 F: 0]NNNNNLLLLNNNLNNNNUNNNtXXPPtUUYYP
Chunks seen      313 [P: 2 F: 0]zzww............................
                  96 [P: 2 F: 0]NzZZUNNXXNNNRRPPZZZZPxXNNnZZXzXP
Transfer list    633 [P: 2 F: 0]ZZZz..Zz........................
                 694 [P: 2 F: 0]YYYYYyyy........................
                 109 [P: 2 F: 0]pzzppxxpznnnppuuRRuuxzzrrnn.....

Rob Bradford: Oh the pain

Fri, 16 May 2008 00:04:46 +0000

Lesson for today: avoid situations such that the GObject dispose vfunc gets called on the same object from different threads interleaved with each other. Bad things happen.

Julien Blache: Obligatory loldebian post

Thu, 15 May 2008 19:33:31 +0000

Because a lolcat is worth a thousand jokes, here are 3 of them.

Thanks to rominet for coming up with those :-)

Joey Schulze: Revival of mod_auth_mysql

Thu, 15 May 2008 15:18:00 +0000

I have finally decided to take over maintainership of mod_auth_mysql, fixed most of the open bugs and uploaded a new version into the Debian archive. Once it has passed NEW it should show up in Debian unstable. Hopefully, it will make it into lenny as well, so that we can provide a version in the next stable Debian release again.

One and a half years ago the former maintainer announced that he has no desire to maintain the package anymore. Since he doesn't use Apache as well that sounds quite logical. Due to a bug that was marked release critical the package has been removed from etch and thus hasn't been released with the current Debian GNU/Linux 4.0 stable.

The package provides an easy way to set up web authentication for certain website locations using account information stored in a MySQL database. This way it was quite easy to use the account data from bugzilla, Mantis, osCommerce etc. for static web pages as well without the need to set up a new account system.

However, since the package has been removed from etch and later from unstable as well, the only way to accomplish this goal is to use and configure »pam_mysql«. For a while I have simply compiled the package from unstable on an etch system which worked as a charm. After it was removed there as well and I was in need again, I decided to find out my options.

In theory »mod_auth_mysql« is deprecated and superseded by »mod_auth_dbd« and »mod_dbd«. The latter package should be compiled with MySQL support and should provide a general database interface for Apache modules – similar to Perl's DBI or PHP's DB layer. Unfortunately Bug#405773 describes a technical problem which makes this approach fail. I'm told chances are good that it will be resolved in the future.

Because taking over a package and simply re-uploading the last version is lame I took a look at the bug tracking system first and fixed eight (+1) bugs before uploading the package. The »MySQL« encryption method works again and doesn't produce a segmentation fault. There's a new encryption method »Apache« that uses the same routines Apache uses for »htpasswd« files. Port specification and boolean options have also been corrected and all Keywords are now available in both spellings to reduce config confusion.