Joachim drew my attention to Openstreetmap.org. So I thought I'd give it a try. Unfortunately the don't seem to have the hardware or bandwidth resources yet for everyday use.

Search results for "München":

City München [en:Munich], about 70km south of Ingolstadt

Village München, about 4km south-west of Bad Berka

Region München, about 1km north of Unterbiberg, Unterhaching

München [en:Munich], less than 1km south of München

[...]

Very funny. München (Munich) itself has 1.3 Million, Ingolstadt about 120k inhabitants. The region around München totals to about 3-5 Million inhabitants, depending on what you consider to be part of the region. But Unterbiberg (13k) and Unterhaching (22k) are officially part of the district of Munich.

The best specification however is the fourth one: If Munich is south of Munich, Munich is also north of Munich, right? So Munich is everywhere, right?

Other search highlights include a Footway "train platform direction Munich".

Nevertheless, the search results make sense, the first result is what I had in mind, and I really like the references they give for each search result.

I wonder if when you type in "San Francisco" it will be like "San Francisco, north of South San Francsico" (no, it's "north of Daly City")

When people think of computer scientists, they think of someone with bad health, a bad skin color and no fitness at all. While there probably are some like that, I actually don't know many. Instead I know people who do things like fighting with sword and rapier. My main sports is advanced lindy hop dancing (which does include occasional aerials and such, but mostly involves 'jumping' around at high speeds). I like dancing most because of the social aspects of it.

Myselfi, I can claim to be the very opposite: I just came back from 5 hours of sports, and I'm not even exhausted, just very hungry. The 5 hours include riding about 13 km in half an hour through the city (and we're suffering from a heat wave these days, with winds from the sahara desert reaching germany), then two full training sessions (that really used to stress me when I started), then the ride back of 13 km again.

My body mass index is 18.something, so I'm slightly underweight, but I actually eat a lot - but I also eat healthy and diverse. Most of my food I cook myself, so I know it's fresh and where I got it from. I'm not vegetarian, I do eat meat about two times a week. I also try to have some variety there, pork, beef, lamb, deer, chicken, ... I don't drink much alcohol and I do not smoke.

So don't stick to that prejudice that computer science people or geeks are physically in a bad shape. You can be both a geek, soical and athletic. The people I know how are in really bad shape actually watch too much TV and such, they neither engage their body nor their mind, nor leave their house much to meet other people.

Since development kernels 2.6.26-rc*, the iwlwifi drivers (iwl3945, iwl4965) have LED support. While LED support is nice to have (making it easy to see when the wireless connection is available), the blinking of the LED whenever there is data transmitted is annoying.

In most networks, there is a constant chatter on the net. Windows server browsing and announcing, Zeroconf/Bonjour announcements, Printer discovery. When you're using some instant messaging or chat such as IRC there is some data transmitted all the time. Your email program might be polling for new emails, and your weather applet might be fecthing the latest forecasts. So basically, there always is ome network traffic. Often in the range of less than 1k/s, but there is.

The new iwlwifi drivers don't flicker the LED with each packet received, but apparently will just set the LED to a blink mode when they received or transmitted some data, which if find rather irritating.

Fortunately, this can easily be configured in Linux, just save this script in /etc/network/if-up.d/iwl-no-blink and make it executable:

#!/bin/sh
if [ "$IFACE" = "wlan0" ]; then
	for dir in /sys/class/leds/iwl-phy*X; do
		echo none > $dir/trigger
	done
fi

This is a quick hack, but it does the job well for me - when the device is connected it will stop blinking on data. It will still blink when connecting (leds:iwl-phy*:assoc) and indicate if the connection is available (leds:iwl-phy*:radio).

GNOME has reacted and removed all blacklisted SSH keys from their authorized_keys, which is the minimum you should do to ensure safety.

For all I know, sourceforge.net has not yet done so (I didn't check if I could have logged in with my old key, though - maybe they installed the blacklist in the SSH server, not touching the users' keys; there is no blacklist in /etc/ssh though). authorized_keys files are world-readable, so I can login at sourceforge and read other users' authorized_keys. With this approach I believe you could hack dozens of SSH accounts on Sourceforge within a few hours, without having to employ brute-force.

These keys could then be used in turn to inject backdoors and/or trojans into other OpenSource projects (where at least one developer with write access did use a vulnerable key).

If you were affected by the Debian OpenSSL bug, please replace your SourceForge key as soon as possible. Please verify any commits made on SourceForge until they've taken appropriate measures to block bad keys.

SourceForge and other operators of such platforms should install blacklists NOW, and remove any vulnerable keys from their databases.

Let me just point out, that the consequences affect all users of SSH. Therefore IMHO all other Linux and BSD distributions need to release a security update to OpenSSH as well, to prevent the use of insecure (too common) keys, because it threatens the security of their systems as well!

Apparently, there are only about 2^15 different keys generated by the SSH versions shipped with Debian for 2 years. It's really surprising that noone noticed this earler. This is just about 32767 different keys. (For each type, size and endianess, but that still makes this number much much much too low) The weakness is caused by a bad random number generator in the Debian package.

Hackers have already generated all these 32767 different keys, for two key lengths and types. In a few hours, they'll also have generated all the 4096 bit keys that could have been generated. Other key lengths are uncommon and sometimes might even be unsupported. Most people use keys with length 1024 or 2048.

So we now have about 32767 keys which are used by lots of Debian and Ubuntu users. That's not very much. Now you have to realize how the keys are used:

The key is used to log into a system without a password. Sometimes a key is protected with a passphrase (you really should do that), but this doesn't help here, because an unencrypted clone of the key was already generated.

Sometimes (or let me even claim 'often') one such key is also used to login as root into a server. This is equivalent to just 32767 different passwords being used as root passwords. So with about this number of tries, an attacker might be able to log into your server as 'root'!

Now the weakness is 'distributed' by the users, it's not just a server-side vulnerability. If your server is running e.g. RedHat, it doesn't mean it is secure!.

In fact, if your server is running Debian and you installed the Debian security update for openssh, it will be much more secure than the RedHat server. Because the Debian server has a blacklist of keys that are too common. The other-Linux server who doesn't have this blacklist doesn't know that a certain 'weak' key is not trustworthy.

Fixing the bad key-generation is just half of the deal. "Recalling" all the keys in use out there is the big challenge, that affects all systems using SSH (and to a different extend, SSL). The most reliable way is if all other distributions would release a security update as well, which refuses to accept the keys that were generated by vulnerable Debian systems.

Let me just repeat it in other words: Any Linux/Unix/*BSD system is vulnerable that grants access to a key that was generated on an affected Debian or Ubuntu system. (Until the system has a reliable detection method of such weak keys.) Keys are usually generated on the users workstation, so if any of your users is or was potentially running Debian or Ubuntu ... you get the idea.

Note that if you are not careful, you might lock yourself out from your server. If you don't have or remember the password, installing the security update might disable your login key. So if your key is bad, make sure to generate a new, secure key and distribute it ASAP. Also remove any vulnerable key ASAP; remember that hackers now have a list of all possible keys and could use that to brute-force login.

P.S. Since some people still don't seem to get the consequences in full: The bigger problem is to remove are the weak keys, not to fix the broken library. The weak keys (especially in the form of public keys!) can live on tons of other systems, not just on Debian and Ubuntu. This is why TOR also released a security update and e.g. CACert urges non-Debian distributors to also ship and use the blacklists of known weak keys. Also note that not all keys that can be considered compromised can be detected this easily. If you've been using a DSA key on an affected system - even when it was created on a different system - it is to be considered compromised.

I've read some more about this and especially had a look at some of the source code, so I've completely revised this blog post.

There is no doubt that the Debian Maintainer who added this patch screwed up, seriously. But he's not the only one to blame:

• OpenSSL isn't valgrind-clean. It should be made, since valgrind is a very important debugging tool; the bad patch was introduced to make OpenSSL better in this respect due to the request by the users.
• The OpenSSL source code could be better documented in these places.
• There are two instances of this line in OpenSSL which can both generate the 'using uninitialized data' warning. One is safe to remove (it's supposed to fill the buffer with random data, and just uses the existing contents as additional source of randomness), the other is not (it's used to feed randomness coming from e.g. /dev/random into the pool).
• The Debian maintainer received the reply "if it helps with debugging, I'm in favour of removing them" by one of the current OpenSSL devs on the openssl-dev mailing list. Probably just referring to the 'safe one' of the two locations where this occurs, though?
• Nobody noticed the severity of this change for more than 2 years. We're all to blame.

I'm really sick of hearing comments like "Still, whoever took out the entire initialization should not be trusted with security intensive code." (guest comment on LWN). Yes, he screwed up there. But you bet he's going to be a lot more careful with any change in the future: he has learned his lesson. Better than having someone else screw up in a similar way again. And actually he didn't do this change half as easy-hearted as many people suggest, if you look at the discussions on the bug report and mailing lists. He was trying to fix the valgrind bug, and he talked to several people on how to do it properly.

The best way the bug could have been avoided was if the OpenSSL upstream developers had cared more about the valgrind issue themselves. (E.g. by teaching valgrind to ignore the issue, documenting in the source code why this is intentional and not an issue, ...)

P.S. in the previous version of this blog post I had asked why OpenSSL apparently relies on uninitialized data for security. It doesn't; the same lines exist in two places, and it's the other change that caused the problems. One place will 'usually' generate the warning, and it's not important (that's the place where you could just remove the line). The other place will generate the same warning when someone passes uninitialized data into the RNG. As long as the RNG is sufficiently seeded with other random data that isn't much of a problem. So if you take a buffer of 1024 bytes and fill it with 1000 bytes of good random data (e.g. from a hardware randomness source) and feed the whole buffer to the RNG, it will be seeded quite well, but the warning will be generated. The 24 uninitizialized bytes won't take the entropy away.

(This blog does intentionally not have a comment function. Sorry.)