Problems with encrypted networks in Fedora

A recently shipped kernel update for Fedora 8 and Fedora 9 broke the wireless support for many users. While an update is already on the way, this shows how difficult it is to provide bleeding edge packages.

One of the greatest features of Fedora is that almost all packages are bleeding edge. And one of the worst bugs in Fedora is that almost all packages are bleeding edge.

This was proven again some days ago, when a kernel update was shipped for security reasons: besides the security patch there were a set of not tested patches included in the new version as well in the new kernel. And that broke encrypted wireless for quite some people.
As described in bug 453390 the bug is well known and updates are already available. But many people might not find that bug report in Bugzilla and will only wonder what happened. In case of myself the wireless network sometimes works (1 out of 10) and I was already wondering if my hardware broke somehow until I discovered the above linked bug report. However, if you run into that bug, just update to the newest kernel in testing and re-try accessing the encrypted wireless network.

However, this shows that having a bleeding edge system can bring up yet unknown problems. Some might think that this could have be avoided by using only strongly tested software versions. But first that takes time, and second, again you need testers. The reason that other distributions can ship such stable packages is in fact that for example Fedora has a large amount of users who are willing to use recent package versions – and test them by using them.
But another way to avoid stupid and silly bugs like this one can be caught by automated tests. Unfortunately, currently Linux seems to lack such wide spread automated testing system.


6 thoughts on “Problems with encrypted networks in Fedora”

  1. The problem seems to be(*) that the new kernel had both the security patch and also other features, or maybe misfeatures. So should the security kernel release have only the security patches on top of whatever was already stable?

    (*) I’m assuming this based on your post, I do not have more detailed information myself. 😛

  2. The problem IIUC is a little more complex than that. Fedora kernel tends to ship the very latest wireless bits ahead of the upstream kernel in part because the wireless subsystem maintainer works for Red Hat and make the right decisions (usually). Unfortunately in this case it seems that the latest wireless bits had a conflict with the security fix that was rushed out urgently. Usually kernels go through updates-testing repository which in theory should catch the major bugs but maintainers can bypass the testing repository for security bugs depending on severity and this in this instance turned out to be problematic. Yes, a good test suite with good tests can catch this problem.

    We have the test framework already for a long time but without actual tests that’s pretty useless. Hopefully we will get tests soon and there are some folks working on this problem for a while in the QA team.

  3. @Rahul: Thanks for the explanation!

    But one question, you said that the maintainers can bypass the testing repository for security bugs. I think this is generally a good idea because security fixes should be released as fast as possible. But probably Fedora should establish a policy that _only_ security fixes can bypass the testing repository. In this situation that would mean that the kernel maintainer would have created a kernel with only the security patch and push them directly into Fedora and than patch this kernel with the new wireless stuff and let them go the normal way through the testing repository.

    Maybe the rule for bypassing the testing repository should be just a little bit more tougher?

  4. “Maybe the rule for bypassing the testing repository should be just a little bit more tougher?”

    I argued for this but I don’t think there was any consensus on this idea. We have to find other ways to deal with this problem I suspect.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s