robert’s rant room

There are only two days left until the LinuxTag in Berlin will start (May 28-31), and Gentoo will be featured with a booth again this year. It’s been some busy weeks for us, and I hope our presentation will turn out to be satisfactory. Even if we do not have the financial backing of other projects.

Speaking of money, if you are still in need of free tickets for all four days, drop me a mail. First come, first served.

If you run any kind of server, especially Debian or Ubuntu, or grant users access to your server, you might want to read the Debian Security Advisory DSA-1571-1 or Ubuntu’s Security Notice USN-612-1 for CVE-2008-0166, and check your encryption keys:

It is strongly recommended that all cryptographic key material which has
been generated by OpenSSL versions starting with 0.9.8c-1 on Debian
systems is recreated from scratch. Furthermore, all DSA keys ever used
on affected Debian systems for signing or authentication purposes should
be considered compromised; the Digital Signature Algorithm relies on a
secret random value used during signature generation.

The first vulnerable version, 0.9.8c-1, was uploaded to the unstable
distribution on 2006-09-17, and has since propagated to the testing and
current stable (etch) distributions. The old stable distribution
(sarge) is not affected.

Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key
material for use in X.509 certificates and session keys used in SSL/TLS
connections. Keys generated with GnuPG or GNUTLS are not affected,
though.

This vulnerability is caused by a patch shipped in Debian, Ubuntu, and other derivatives. Gentoo’s OpenSSL version is not affected, but everyone should check user-provided public keys (such as OpenSSH’s authorized_keys) using the Debian/OpenSSL Weak Key Detector.

Update: Ben Laurie of OpenSSL is making a point that Vendors Are Bad For Security, which I would not follow in that general form. What I have to grant him: Mechanisms of peer review must be employed properly and patches discussed with upstream. If you follow this philosophy, Vendors Are Good For Security.

If you are like me and have a lot of good friends that use Debian-based GNU/Linux systems, you were probably envious that their Firefox uses a much nicer icon set, and a different name: Iceweasel. The reason lies within the fact that Debian removes unfree parts (like binary plug-ins) and was therefore forced by Mozilla to use another name and logo, as Firefox’ trademark policy forbids distributing patched versions under that name.

In Gentoo, if you compiled Firefox from source, you could either choose between official branding with the risk of trademark issues if you distribute binary packages, or Firefox’ default theme, “Bon Echo”. Thanks to our Mozilla grandmaster Raúl Porcel (armin76), we now also have the Iceweasel branding available, the USE flag is called “iceweasel”. It does not remove any parts of Firefox except icons and names, that is still your job to do. Thanks, Raúl. I don’t have to envy anymore!

Short version: RESTRICT=”mirror” for 24 hours.

Long version:

Fixing some security bugs in teTeX yesterday, I came across a problem that only happens when upstream really messes up: Changing their tarball and leave the same name.

This is disruptive as the user/portage can decide to download either from one of Gentoo’s mirrors or the SRC_URI, but he has one checksum for the file it expects. So we have two options now: Mirror the old file ourselves, changing SRC_URI to mirror://gentoo/ or update the file on our mirrors.

The latter is not a trivial thing to do though: Just changing the checksum and upload the new ebuild could cause serious damage to users. The tarball was 100 MB big and if a user has ten mirrors set up, 1 GB of traffic could be caused before downloading from SRC_URI. Solar came up with a great trick here:

1. Change all ebuilds referencing that file to RESTRICT=”mirror“.
2. Change the checksum of the distfile.
3. Wait a day.
4. Remove RESTRICT.

This will probably cause least damage (ok, it’s second to renaming the file). Users with current trees will download the new file from the SRC_URI. If they have the old file still on their disk, portage will download a new one. Users with old trees will find the file on the mirrors until some hours after (2). They have to re-sync or die a very painful traffic-death.

And that’s why you should

1. always emerge --sync before updating anything.
2. never ever re-release a file with the same name.

Old news for those who follow commits and bugs, but last week KNetworkManager hit the portage tree after living in the Gentopia overlay for a while.

Why did it take so long?

I know Gentoo is one of the last distros to feature this. One reason this took so long is that I learned about it quite late (a friend of mine switched to Debian because Gentoo didn’t have it). Also, it was my intent to enable VPN support in KNM before committing it. As the KNM is a GUI for the famous NetworkManager, it only can do what NM features. VPN support in KNM thus depends on VPN support in NM itself.

NetworkManager releases

Here’s where the problems begin: The NetworkManager moved its homepage over to gnome.org, and lost its VPN releases on the way. Compiling the VPN plugins from SVN didn’t work with the latest release (even from releases’s branch). Also, I don’t understand their release policy. They got some work done in the stable branch all the time. Every distro is shipping snapshots of it, but we didn’t see a release for almost a year. So what changed for Gentoo?

• We have a (hopefully) working snapshot of net-misc/networkmanager, called 0.6.5_p20070823.
• We have a KDE GUI for it, called kde-misc/knetworkmanager-0.2 (hey, an actual release)
• We have three VPN plugins: net-misc/networkmanager-{pptp,vpnc,openvpn}. Read on if you’re interested in them.

What does which package give me?

Basically, the packages in net-misc/networkmanager only feature command line tools that do the background work. You can install them in two ways:

• If you need GNOME support, enable the gnome use flag for any/all of them. That also installs gnome-extra/nm-applet for you.
• If you need KDE support, install kde-misc/knetworkmanager and enable the VPN use flags you need.

Be sure to add the packages to your package.keywords so you can install them on a stable system.

WLAN Support

Ok, this is the great part! Configure your wireless network via a GUI. No more editing weird config files once you move your laptop, no iwlist. Just select the network you want and get on with it! KNM can even store your keys to your KDE wallet. Any user may change the internet connection without root privileges when he or she is in the plugdev group.

VPN Support

The VPN plugins are SVN snapshots of the stable branch. The pptp plugin is currently p.masked because its GNOME gui segfaults on amd64. This bug was obviously fixed in the trunk, but the trunk code is not usable with stable versions of (K)NetworkManager. I’ll have a closer look at this later. The other plugins seem to work, but I couldn’t do extensive tests yet (where’s my vpnc password?). Please report failures to me on our Bugzilla. When reporting, be sure to attach the relevant parts of your syslog (”grep Network /var/log/messages“) or start NetworkManager in non-daemon mode (”NetworkManager --no-daemon“). If you succeed on using them, please leave a report here.

Acknowledgements

Thanks to Steev for the maintaining the ebuilds of NetworkManager itself and testing!

Writing a bug report is a hard thing to do. I know. Fortunately, there’s some easy rules to follow when you want to get it fixed and fast! To ease your understanding, I will illustrate them with some real-life examples:

1. Scream. It’s so easy to write upper-case (thanks for caps lock!). And for most people, they’re much easier to read. They’re stupid anyway, so they’re probably used to being screamed at. So start with a nice “OH MY GOD. What went through your head when you did this?”, then go on explaining your problem: “gcc is FUCKING SLOW”.
2. Annoy. If possible, mark the bug with highest priority and severity. You filed it, so you decide on how important it is for others! After you expounded your problems that verbosely, say something personal. This helps: “You should be ashamed of yourself.”
3. Show that you’re annoyed. There’s quite some ways to do that. Use your fantasy, remember how you did that when you were a child. “Even Apple and Microsoft would be ashamed of fucking up this badly.” or “What a great distro you have there. Debian would be proud of you.”
4. When people ask questions, insult them. Really, they shouldn’t try to reproduce the bug anyway. Why would they want to have the bug themselves, instead of just fixing it! “I’ll give you personally ten bucks if this helps you debug the issue. … I dare you to tell me how the emerge –info helps you. Do it publicly, please, so the humiliation is greater. “
5. Threaten. If not everyone will know how important your bug is to you until here, you should make that clear again: “But apparently Gentoo is not interested in fixing bugs. … Don’t bother. I’ll switch distros.”
6. Propose bad solutions. This is actually hard. You have to distinguish your solution from the way it is right now (”This whole construct is braindead.”) Remember not to ask or think about the reasons why it’s the way it is right now.
7. Point fingers. “This is so unbelievable that I will blog about it, too.”

Sadly for the example, following these steps didn’t fix the bug. Another report did.