is a GPL-licensed replacement
firmware for a number of digital audio players. LWN published an article
on the imminent
Rockbox 3.0 release in May, 2006. Well over two years later, it is
clear that some projects use a larger value of "imminent" than others. In
this case, the Rockbox developers concluded that certain problems simply
were not going to be resolved in any reasonable 3.0 time frame; rather than
make a major release with known problems, they simply gave up on 3.0 at
that time. As a result, the current stable Rockbox release is Rockbox 2.5
from September, 2005.
It is probably safe to bet that few Rockbox users are running 2.5, which
only had support for a handful of Archos players. Grabbing a daily build
is a fact of life in the Rockbox community. Meanwhile, Rockbox has
performed a valuable service for Debian developers who would otherwise have
to struggle to find a project with longer release cycles than their own.
Perhaps that state of affairs is about to change. Back in July, the
project announced that, once again, an
attempt was to be made for a 3.0 release. On August 15, Rockbox went into feature freeze, with the 3.0 release
planned for "within a couple (as in two) weeks." That, of course, was a
few (as in three) weeks ago, but this release is clearly getting closer.
Now would seem like the time for the project to begin its hype campaign
with lots of screenshot-heavy articles on all of the features this major
release will bring. Evidently the Rockbox developers have some strange
ideas about actually working on the code, though; they haven't gotten
around to the promotional side of things yet. So, while the Rockbox manual is reasonably
comprehensive and current, it's hard to come up with a list of changes for
the 3.0 release.
At the top of any list would have to be the list of supported players,
which has expanded considerably since the 2.5 release. The Rockbox
buyer's guide gives a good summary of the currently-supported players.
Alas, none of these players are currently in production, though some can
still be found on auction sites and elsewhere. There is progress toward
support for some more contemporary players; early successes have been
announced for the Cowon iAudio D2 and iAudio i7 devices. Those players will
not be supported in the 3.0 release, of course, and the Rockbox developers
have reserved the right to withhold support for other players as well if it
is not stable enough.
Beyond that, changes to Rockbox in recent times include the ever-growing list
of codecs (including some video formats on suitable players), a
five-band parametric equalizer, an increasingly powerful theme capability
user-contributed themes, album art display, a highly capable tag
database, Speex codec support for the
voice-based interface, and a whole host of new plugins including the
plugin which displays a blank screen at full intensity, turning your
player into an expensive, short-lived flashlight. Rockbox 3.0, it
seems, will have something for almost everybody.
that installation can be a bit of a sweaty-palms experience overshadowed by
the fear of turning that nice, new player into a brick, any help which can
be given is more than welcome.
It also appears that 3.0 may include the hard-to-find RBUtil program - a
Qt-based tool which automates the process of installing Rockbox. Given
that installation can be a bit of a sweaty-palms experience overshadowed by
the fear of turning that nice, new player into a brick, any help which can
be given is more than welcome. Bricks, after all, are not known for
Another recent event in the Rockbox community is the creation of the Rockbox
Steering Board, currently consisting of Daniel Stenberg, Linus Nielsen
Feltzing, Dave Chapman, Paul Louden, and Jens Arnold. The mandate for this
board is not particularly clear; it seems to be intended to help break
deadlocks in technical discussions. There have been some concerns raised that the creation of this
board is a sign that Rockbox is moving into a more bureaucratic,
slow-moving mode, but those worries are probably premature.
Rockbox developers also recently decided
that all of the project's code would be licensed as "GPLv2 or later."
While there is no plan for Rockbox to switch to GPLv3, the developers
wanted their code to be available to other projects which are using that
license. Since Rockbox does not require copyright assignments, this change
will require an audit to find any GPLv2-only code and either relicense it
or remove it. There have been no public announcements on how that process
The Rockbox project faces a number of challenges. Cooperation from vendors
is essentially zero, so all ports require a reverse engineering effort.
Target platforms go through their market lifecycle quickly, making it
difficult to get a port stable before the target device disappears. Its
programming environment is highly specialized and resource-constrained,
limiting the pool of developers who can work on the project. And, someday,
the whole effort may lose its relevance as platforms become more capable
and it gets easier to just run Linux on them. For now, though, there is
nothing better for those who want a dynamic and user-oriented operating
system for their digital audio player, and it continues to improve.
Comments (11 posted)
The Fedora project is back on track after its recent "infrastructure
issues" with new package signing keys as well as packages and updates
signed with the new keys. Fedora users should be able to pick up the new
key and update their systems now, with a minimum of hassle—just
accepting the new key. But, no further information has been released about
exactly what went wrong, leading to more speculation and
some worry in the Fedora community.
When a user gets a package from their distribution—or, more likely, a
mirror of their distribution repository—they need to have some way to
determine that it is a valid package. Distributors sign packages using a
private key; that signature can then be verified by using the
distribution's public key. If the private key gets compromised somehow,
malicious packages could be created that would be indistinguishable from
the real versions. This is why private signing keys must be well guarded,
usually by isolating them on separate machines and encrypting them with a
According to one of the announcements
about the problem, there is no evidence that the passphrase used to guard the
Fedora private signing key has been compromised, though the clear
implication is that the encrypted key file may have been captured.
Out of an abundance of
caution—and perhaps the concern that the passphrase might be guessed
or brute-forced—the project decided to generate new keys. Along with
new keys come various headaches: re-signing all of the packages as well as
getting the keys installed on user's machines.
Getting the keys to users is largely a matter of getting the new
fedora-release package—along with PackageKit and friends for
GUI-enabled updates—installed. That package contains the new key and
repository name (updates-newkey). Of necessity, those updates are the last
that will be signed with the old key, so they will install on existing
Fedora systems. Once that package makes its way out to the mirrors, users
can install it so that they can proceed with any needed updates using the
A yum clean metadata was helpful at the time of this writing to
accelerate the process; depending on which mirror is being used and when it
gets updated, that may not be needed. After fedora-release is
installed, yum list updates gives a long list of updates
available, all signed with the new key. All a user needs to do is verify
the key and add it to the RPM key database. Verifying the key is a manual
step as a user must
check its fingerprint against that published on the web site. The
method described requires importing the key into gpg, then doing
gpg --fingerprint email@example.com to see the key
fingerprint; this is clearly something that could be made easier.
As part of phase one of the re-signing, Fedora has re-signed all Fedora 8
and 9 package updates. Phase two is ongoing, re-signing each package that
is distributed as part of the original release of Fedora 8 and 9. Fedora
10 already has a new signing key as well. From the perspective of a
possible compromise of the signing keys, things are well on their way back
to normal. But there is still the nagging issue of how this all came about to
Several different questions about the intrusion were directed at the Fedora
community members in their IRC meeting on
September 9. Unfortunately, there was no new information forthcoming,
nor was there any indication of when that information might be available.
According to the board member Tom "spot" Callaway, information will be
released "when we're told that we can by the parties running the
investigation, not a second before, and not a second later."
Red Hat is clearly holding all information about the intrusion as a closely
guarded secret—whether that is at the behest of law enforcement or
just lawyers is unclear. While there was no timeline given, the clear
sense that one got from the meeting is that it might be weeks or months
before clearance will be granted to even confirm that they know how the
In addition, the Fedora board has not been officially briefed on the
incident; some members have knowledge because of their Red Hat
responsibilities, but the rest are in the dark. If one needed a reminder
that Fedora is not an independent distribution, but instead is subject to
the whims of Red Hat, this is a clear demonstration.
The justification for secrecy is that Red Hat is a publicly traded company
so intrusions into its systems need to be treated differently. Some board
members believe that had there not been an intrusion into the servers that
handle packages for Red Hat Enterprise Linux—that is if it had only
been Fedora servers that were affected—the incident would have been
handled much more transparently. Overall, the board is clearly unhappy
situation but, perhaps because they are almost all Red Hat employees, don't
see that there is much that can be done about it. That too should serve as
It should be noted that Debian has had several server compromises over the
years (for example, 1 and 2), which is, perhaps, a poor
record of server security, but it is an excellent example of
transparency. Debian is rather well known for its independence, which is
part of what allows it to be so open. Those incidents do serve as
examples; perhaps they are not an exact fit for the current Fedora/RHEL
intrusion but that remains to be seen.
It may very well be that Red Hat is between a rock and a hard place here.
As a friend to free software, Red Hat is unparalleled, but once in a while
it shows that it is foremost a corporation with responsibilities to its
shareholders. When those responsibilities conflict with the transparency
we have come to expect from free software projects—especially with
regard to security issues—that transparency must be set aside. One
can argue that Red Hat is being overly protective of the
details—confirmation that they either know or do not know how the
intrusion occurred for example—but that argument really can't be made
until all the facts are known. For that we must wait for the process to
run its course.
Comments (28 posted)
Earlier this year, your editor asked a high-profile kernel developer, in a
public discussion at a conference, about the seemingly large number of
kernel-related security bugs. Was the number of these vulnerabilities of
concern, and what was being done about it? The answer that came back was
that security issues aren't a huge concern, that most of the reported
issues were obscure local exploits requiring the presence of specific
hardware. Serious issues, like the vmsplice()
, are rare.
More recently, as part of the panic associated with getting a talk together
for the Linux Plumbers
Conference, your editor decided to take a closer look at kernel
vulnerabilities. It turns out that there are, in fact, quite a few of
them. The vulnerabilities which have been given CVE numbers in 2008 (so
That is 41 CVE numbers (so far) for 2008 - not a small number. Fully 1/3
of these vulnerabilities were in the networking subsystem, which is scary:
this is the most likely place to find remotely-exploitable problems in the
kernel. It is true that sites not running SCTP or DCCP can forget about
many of those, and IPv6 is responsible for a few of the rest, so most of
those vulnerabilities were not a concern for most sites.
Many of the
remaining vulnerabilities were in the core kernel or in
The number of vulnerabilities found in drivers - the part of the kernel
which has long been sneered at as containing the worst code - is actually
quite small. On the other hand, four of the CVE-listed vulnerabilities
(the Xen, AppArmor, and utrace problems)
were caused by out-of-tree code added by distributors. There is no way to
know how many vulnerabilities were fixed without obtaining a CVE number - or
without even realizing that a vulnerability existed in the first place.
When a single program is responsible for this many vulnerabilities, it
makes sense to ask why. The kernel, of course, is a very large program;
more code means more bugs, some of which will have security implications.
Beyond that, though, the kernel runs in a special, privileged environment.
Flaws which would simply be fixed as just-another-crash in a normal
application are denial-of-service vulnerabilities in the kernel - or
worse. So a larger number of vulnerabilities in the kernel does not, by
itself, imply that the kernel's code is worse than that of other programs;
it only reflects the fact that the consequences of kernel bugs tend to be
The discovery (and repair) of vulnerabilities does not necessarily imply
that our current process is creating a lot of vulnerabilities; it could be
that we are mostly fixing older problems. If the developers are
fixing vulnerabilities more quickly than they are adding more, life should
be good in the long run. The vulnerabilities in the list above vary from
those which are very old (affecting 2.4 kernels too) to some which are very
new (the UVC driver was added in 2.6.26). Some of them are in code which,
while being intended for the mainline, has not yet been merged. It is
probably impossible to say whether security problems are being fixed more
quickly than they are being created, but one thing is clear: all of that
code flowing into the mainline is bringing a certain number of security
problems with it.
For that reason, it is a little discouraging that there is little work
being done in the kernel community with the explicit goal of improving the
security of the kernel. Few patches are reviewed with security issues in
mind; the vmsplice() vulnerability, as one example, was a clear
failure of the review process. There are undoubtedly many people who are
doing fuzz testing and such - some of them are even the good guys - but
much of the formal testing going on seems aimed more at API conformance
than at security verification. There must be more work going on behind the
scenes, but it is still hard to avoid a sense of a certain amount of
complacency with regard to security issues.
As a community, we take pride in the security of our system. But one
vulnerability per week is not the most inspiring security record. It would
be good to find a way to do better than that. Better tools must be a part
of the solution, but more thorough code review is also needed. There still
is no substitute for a pair of eyeballs looking for ways in which new code
might be subverted. Asking for more security-oriented review seems
ambitious when code review is already one of the biggest bottlenecks in the
development process. But the alternative would appear to be to continue to
add to our collection of CVE numbers.
Comments (77 posted)
Page editor: Jonathan Corbet
Next page: Security>>