| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for January 8, 2004Red Hat borrows $500 million Red Hat has a balance sheet that many other companies would envy. The company was lucky (and smart) enough to be the first Linux company to go public during the brief Linux portion of the dotcom bubble; it even had sufficient time to do a second offering to bring in another pile of cash. That windfall, along with careful management, left the company with $329 million in cash and investments at the end of November, 2003 (the last quarter for which numbers are available). That cash pile has been growing in recent quarters; Red Hat certainly need not be concerned about running out of money anytime soon.So one might well wonder why Red Hat has just issued $500 million in bonds. Why take on half a billion dollars in long-term (20 years) debt when you haven't really figured out what to do with the cash you already have? We asked the company, and were told:
We decided to take this great opportunity to capitalize our company
for the purpose of achieving our goal to become the defining
technology company of the 21st century. We are focused on building
and expanding our organization long term.
There are no specific plans for the cash at this time. In other words, they aren't telling. One may well speculate that there are acquisitions (big ones) in the works; this idea is reinforced by this (Raleigh) News & Observer article:
"We believe the time for us as a company to take control of the
market is now," said chief financial officer Kevin Thompson. "What
we've done is capitalize ourselves so that we can react very
quickly to opportunities that come up in the marketplace."
Customers are demanding products that Red Hat can't offer, Thompson said. It likely will have to buy other companies to add new products and services. One assumes that Red Hat has some "opportunities" in mind, but they are not ready to talk about them at this time. The truth of the matter is that Red Hat was able to get this money on great terms. The interest rate on this loan is 0.5%. So Red Hat could simply put the money into certificates of deposit (currently paying 4% or so in the U.S. for long terms), pay off the loan in 20 years, and pocket the interest. If Red Hat invests this money in this way, it has just acquired a few million dollars per year in free income for the next two decades. This is not a deal the company could afford to turn down. The real question, perhaps, is why the (unnamed) investors decided to loan money to Red Hat on such terms. Long-term U.S. treasury bills pay 4.2% as of this writing - eight times what Red Hat is paying. The U.S. government is unlikely to reinvest such money as wisely as Red Hat, but it has the advantage of its coercive powers when payback time comes. Treasury bills pay more, and are safer too. The answer to that question can only lie in the conversion feature of these bonds. The purchasers can convert the bonds to stock at a rate of about $25/share at any time. That rate is significantly above Red Hat's current stock price ($18.50, as of this writing) but, remember, these investors are working with a twenty-year horizon. The bonds are, essentially, a long-term call option which enables the investors to get their funds back if the stock price never goes above $25. Unless Red Hat goes into bankruptcy, the bond holders will probably do OK. Red Hat started the first Linux financial boom with its IPO. What we may be seeing here is the beginning of the second, more sustainable boom. Serious money is, once again, flowing into Linux companies. The first boom changed the industry in many ways, and left numerous investors rather poorer than they were before. The second boom may be seen as when Linux really took off; it will doubtless bring changes as well. As always, it is going to be interesting to watch.
LWN's Obviously Incorrect 2004 Predictions The new year is upon us, and so, like many other publications, we feel an irrational urge to wave our hands in the air and make predictions for what we think the coming year will bring us. So here we go. Needless to say, anybody who is thinking of acting on any of the following would be well advised to get a second opinion...
Enterprise LinuxThe "enterprise Linux" business came into its own in 2003, as Red Hat, in particular, found a steady stream of willing customers which drove the company into a profitable state. Red Hat's enterprise offerings must be providing value to the company's customers, given the claimed 90% renewal rate on enterprise support contracts. But the per-system licensing of Red Hat Enterprise Linux has rubbed some community members the wrong way; many developers feel that Red Hat's contracts do not reflect the sort of world they thought they were helping to build. So, we predict that, in 2004, the enterprise Linux backlash will grow, and we will begin to see whether that backlash can change the enterprise Linux market. A number of free enterprise Linux projects are out there, including CaOS, Whitebox Linux, and UserLinux. These projects have an uphill road ahead of them; to be successful, they will have to convince skeptical companies that they will be able to provide high-quality support for many years into the future. They will also have to make independent vendors see them as important enough to certify applications for. Oh, and, of course, they will have to create a top-quality distribution aimed at the needs of this sort of customer. Creating that distribution will not be easy, but it may prove to be the simplest of the challenges faced by any would-be challenger to Red Hat's enterprise offerings. The interesting thing is, of course, that these challenges look remarkably similar to those faced by Linux itself a few years ago, when the idea that Linux could pull the rug out from under proprietary Unix systems and challenge Microsoft seemed ludicrous to many. But it happened. Now, challenging enterprise Linux with truly free Linux looks like a daunting task. But it may yet be that a free distribution combined with a distributed network of supporters could supplant today's enterprise offerings in just the same way that Linux has taken Unix's place. The community is capable of amazing things. Not everybody would see such an event as a good thing, but it could happen.
Desktop LinuxThe desktop wars will heat up again in 2004. For those of us who remember the KDE/GNOME flame wars of years past, the relative calm and cooperation which has prevailed more recently has been a welcome thing. But there are pressures building which threaten to upset the peace.The first of those pressures is licensing. Ironically, KDE's choice of the GPL for its libraries may work against it here. The looser GNOME library licensing allows its toolkits to be used, royalty-free, with proprietary applications. Proprietary KDE applications can only be distributed by paying royalties to Trolltech, which owns the Qt libraries. Many users and developers would rather not see proprietary applications exist at all, or, at least, not without paying those who have developed the underlying toolkit. These people are happy with KDE's licensing. Most users, of course, don't care. Distributors, however, usually want to enable vendors to sell applications on their platforms. This interest will push them toward the GNOME camp. The other point, however, is that distributors are increasingly under pressure to make a choice. Supporting two desktop systems adds to the total workload of maintaining a distribution, and that costs money which may not be available. There is a common perception at this point that the two desktops are functionally identical in all the ways that matter; if that is true, why bother with two of them? In 2004, these pressures will lead to rising emotions in the camps of both desktops as they see decisions being made for or against them. Perhaps the result will be a greater degree of cooperation between the two development communities via freedesktop.org or other mechanisms. Or, perhaps, our newsgroups, web sites, and mailing lists will once again play host to heated debates and flame wars in vain attempts to establish one desktop as being superior to the other. Beyond that, however, the hackers will stay busy and desktop Linux will amaze us again. In 2003, it was widely recognized that Desktop Linux has everything that many, if not most, business users need to get their jobs done. 2004 will be the year that desktop Linux stops playing catch-up (in some areas, at least) and truly begins to blaze interesting trails of its own. Projects like Dashboard, GNOME Storage, and Reiser4 are just the beginning of a wave of innovative projects which will change how we use our computers. 2004 may not, however, bring Linux into many more homes. A Linux system is more than adequate for Grandma to send email and wander around on the web. Your editor insists that his children use Linux for their email, browsing, and homework tasks, and it handles those jobs well. The sad truth, however, is that there still needs to be a Windows system around for other vital tasks - such as playing games. Home users are not interested in dual-boot systems; until Linux can do everything they need, they will stick with the same old stuff. Linux may eventually have a free application base which replaces many of the commercial offerings currently filling the shelves of computer stores, but it remains hard to imagine free games, for example, which can compete with the hit-driven commercial variety. Until there is a lively market for commercial Linux applications, there will be some hard limits to how many desktops we can occupy.
Legal issuesThe SCO case will drag on, and become more complicated, in 2004. IBM may well succeed in getting many of SCO's complaints dismissed early in the year, but SCO probably has a good chance of keeping some of its breach of contract charges alive. SCO may have to retreat to some of its earliest charges (i.e. JFS, RCU, NUMA, SMP), but IBM may have to go to trial to prove that its code in those areas is not derived from SCO's Unix. SCO can probably muddy the waters enough to keep the judge from dismissing the case outright.Even if the IBM case is dismissed in 2004, however, there is the issue of SCO's threats of copyright infringement suits against Linux users. One may be tempted to dismiss these threats as just that much more empty SCO bluster. It is worth considering, however, the pressures that SCO will be under, including the agenda of its lawyers and the looming "dividend" payments on the BayStar investment. SCO has no hopes for increasing revenue from its remaining software products at this point; it must litigate further to bring in cash. With the lawyers in charge, chances are that SCO will, indeed, launch new suits. In fact, the company may well find backbone-challenged Linux users that will cave in and pay up rather than risk a court battle. Such an event will do short-term wonders for SCO's stock price and cash flow. The simple fact is, however, that the SCO Group has still put forward very little evidence to back up its claim, and what evidence it has presented has mostly been laughed off the stage. The company's claims to own the "Unix ABI" will get no further. Beyond that, Novell's new copyright assertions have the potential to stop the show dead, at least until that dispute has its own day in court. But, regardless of the validity of Novell's claims, SCO's case is empty and the world, increasingly, is seeing that. By the end of 2004, the SCO cases will probably still be alive in some form, but the end will be in sight. As an aside, Novell will face a severe test of its credibility in the eyes of the community. Nobody wants to see the SCO case resurrected in the future by a Novell which, perhaps after a management change or two, decides that its Unix copyrights (if they are Novell's) might yet be worth something. If Novell is serious about being a part of the Linux community, it needs to make a statement, soon, about just what it intends to do with the Unix copyrights it claims to own.
The GPL may have its day in court. The SCO Group has, of course, stated its intent to break the GPL in court. But that company's arguments, thus far, have failed to impress. SCO's GPL challenges should not get far. More interesting GPL-oriented cases may come from a different direction. Many developers working in the industry are full of stories of rampant GPL violations, especially where embedded systems are involved. Last year's episode with the LinkSys WRT54G router is just the small tip of a large iceberg in this regard. To an extent, people have been willing to look the other way; it just hasn't seemed worth the trouble to challenge closed-source uses of GPL-licensed code in many cases. There are developers, however, who are increasingly unwilling to close their eyes to violations of their licenses. Expect more challenges against vendors using GPL-licensed code in non-licensed ways. The lack of any court decisions on the GPL will eventually embolden a violator to try his luck in front of a judge. At that point, we will begin to see what the judicial system really thinks of the GPL. Security2004 will make us care more about security. In 2003, we saw an ominous string of attacks against the servers which support the Linux development community. There is no reason to believe that these attacks will stop anytime soon. Sooner or later, perhaps in 2004, somebody is going to do some real damage on a scale we have not yet seen. A major breach, perhaps compromising the systems of many Linux users, will cost us money, time, and much credibility.In recent years, most attacks against Linux systems have exploited known vulnerabilities for which patches existed. A well-managed site is nearly immune to attacks using known vulnerabilities; all of the major distributors are quite good (usually) about quickly preparing updates when a problem comes to light. The attacks we saw at the end of 2003, however, made use of previously unknown holes in rsync and the kernel. Defending against unknown vulnerabilities is much harder, and there do exist attackers who realize this, and who are smart enough to find such problems. In the coming year, we may well see some truly scary exploits of this sort of "zero-day" vulnerability. There is some good news, however. By the end of 2004, we will see wider deployment of hardened Linux systems. The incorporation of SELinux and various other security technologies into the Fedora Core distribution (and, from there, into Red Hat Enterprise Linux) will drive much of this deployment, and threats from the outside will do the rest. Adding SELinux is a significant step in the evolution of Linux distributions; if this work is done properly, Linux users should soon have a much higher level of security available with a default system install. Proper containment of security breaches should, for example, make that next web server buffer overflow be much less of a threat than it is now.
Kernel2.7 kernel development will begin after the 2.6.0 kernel has had a few months to stabilize. Expect the 2.7 development series to be quite different from 2.5, however. By the time that 2.5.0 came out, there was a massive backlog of patches waiting for inclusion. The 2.4 stabilization process had taken nearly a year, and there was a long shopping list of planned changes for 2.5, including the block layer rewrite, expanding the dev_t device number type, a new loadable module subsystem, a new kernel build mechanism, asynchronous and direct I/O, and many others.On the eve of 2.7, the "patch pressure" is far lower. There's no end of ideas for 2.7, including virtual memory work (page clustering, shareable page tables, etc), the never-ending desktop interactivity work, and much internal reworking to eliminate race conditions, and so on. But many users are (or will be) far happier with 2.6 than they were with 2.4, and the list of features that the Linux kernel must have to not be jealous of its Unix predecessors is shrinking. The Linux kernel is maturing, in other words. It may well be that, with 2.7, the pace of change begins to slow a little. Or maybe the kernel hackers will come up with some amazing new ideas and run with them; at that point, all bets are off.
To conclude...It's going to be an interesting year. That, perhaps, is the only truly safe prediction to be found among all the others on this page. All the rest are offered with no warranty as to their veracity, suitability for any particular purpose, or connection with any sort of reality whatsoever. LWN.net does not provide indemnification for users of its predictions - though purchasers of our "predictions license" (available for a limited-time special half-price deal through January, 2007) will get a promise from us to not sue them.
Some LWN notes We recently received a message complaining about the lack of "LWN status update" news in recent times. It is true we have backed off on such articles; LWN should carry the news, not be the news. But, for those who are wondering, here's a brief update.When we started the subscription program, we set our goal at 4000 individual subscribers as a minimum needed to keep going. We have not achieved that goal; there were just over 3000 subscribers when the "great expiration" hit at the end of September. At that point, about 1000 subscriptions ran out over the course of a few weeks. We have since clawed our way back up to just under 3000 subscribers again. It is gratifying, to say the least, that the renewal rate was so high. 3000 subscriptions is sufficient to keep us going for now, but we still need to find a way to increase that number substantially. We are pondering various ideas; stay tuned over the next few months as we figure out how to proceed. Meanwhile, thanks to the generosity of the folks at HP, LWN editor Jonathan Corbet will be attending (and speaking at) Linux.Conf.Au from January 14 to 18. We look forward to reporting from what is, by all accounts, an outstanding conference. There is also a distinct appeal to going to a place where the temperature is above freezing. Finally, LWN.net will celebrate its sixth anniversary in about two weeks. Six years ago, we could never have dreamed of the directions LWN would take us - it was, after all, simply intended to be an attention-getter for a Linux consulting and support company. It has been (and continues to be) a great ride, however, and we expect to keep doing this for a long time. Thanks to all of you for being such a great and supportive reader community.
Page editor: Jonathan Corbet Security The Savannah Compromise - what really happened? 2003 hasn't been a banner year for computer security, and that includes Linux. The CVS repository for the Linux kernel was attacked (if clumsily), several servers related to the Debian project were compromised, and the GNU Project's Savannah server was also broken into recently. Since there has been little information published about the nature of the Savannah compromise, we contacted Bradley Kuhn, executive director of the Free Software Foundation for more information.Kuhn described the Savannah compromise as "almost identical to what happened to Debian." (A detailed account of the Debian compromise can be found here.) Kuhn said that he believes that the Savannah compromise and the Debian attacks were related, and happened at about the same time. However, he said that the project has not put a great deal of time and effort into analyzing the attacks because it was more important to put Savannah back online and to try to harden the system to see to it that a similar compromise doesn't happen again. The hard drives from Savannah have been saved for future reference, but the project is not putting its efforts into thoroughly analyzing the attacks. For the most part, Savannah has been restored and changes have been made to try to ensure a similar attack will not be possible. However, there are still some features that remain unavailable, including Web CVS access and new projects are not being approved for the time being. According to the Savannah website, new projects will probably be accepted sometime before the end of January, 2004. Has there been an attempt to insert a trojan into any of the code residing on Savannah? Kuhn says that they've asked the owners of projects on Savannah to go through and verify the code that is on Savannah to be sure that it hasn't been trojaned. So far, there have been no reports of tainted code. However, not all of the projects have reported their status. Kuhn also noted that projects on the Savannah website will soon have an indicator to report whether or not the developers have verified that they have checked the integrity of their software. We also asked if there was any sensitive information on Savannah that may have been compromised. Kuhn said that the useful information on Savannah mostly consists of the code for the various projects, and that the only other information of interest would be developers' passwords. The passwords on Savannah have been reset, of course, and the developers have been encouraged to "investigate their own personal security." For now, the GNU Project is not actively pursuing criminal prosecution of the attacker or attackers. Kuhn says that the project is not "ethically opposed" to prosecuting the intruder, but that with limited resources he'd rather divert time and energy to restoring the services and trying to harden systems to make future attacks more difficult and easier to contain. To that end, the compromise may actually be a good thing in the long run. Kuhn said that they have contacted the CVS maintainers and have offered to pay for development of features that would allow GPG signing of commits through CVS -- making it much more difficult for changes to be inserted unnoticed into code held in a CVS repository. He said that they have also contacted the GNU Arch maintainer about adding GPG signing. Though it may take some time to develop, the addition of GPG signing to commits would be a welcome feature. Kuhn said that he expects that the future will bring more attacks on the community, as free and open source software become more prevalent. Opponents of the open development model will no doubt be using these events as an illustration of the "dangers" of open source. Though the recent intrusions have mostly been an inconvenience, it's important that the community learn from these attacks, and redouble efforts to prevent them in the future.
New vulnerabilities cvs: possible root compromise
fsp: buffer overflow and directory traversal
jabber: denial of service
kernel: two vulnerabilities in 2.4.23
mpg321: format string vulnerability
nd: buffer overflows
xsok: bad privilege handling
Updated vulnerabilities apache: buffer overflows in mod_alias, mod_rewrite
apache2: Denial of Service vulnerability
bind: cache poisoning
CUPS: denial of service
ethereal: protocol dissector and other vulnerabilities
Filename disclosure vulnerability in fam
fetchmail may crash on specially crafted message
fileutils/wu-ftpd: denial of service
glibc: DNS stub resolvers contain buffer overflow vulnerability
GnuPG: ElGamal signing keys compromised
gtkhtml: malformed messages cause crash
iproute: local denial of service
kernel: local root exploit in 2.4.22
kernel-utils: setuid vulnerability
lftp buffer overflows
libnids: remotely exploitable buffer overflow
libpng, libpng3: buffer overflow
mikmod: buffer overflow
mpg123: heap overflow
mplayer: remotely exploitable buffer overflow vulnerability
Nessus NASL scripting engine security issues
Net-SNMP: security bugs in versions before 5.0.9
nfs-utils xlog() off-by-one bug
openssh: timing attack leads to information disclosure
postfix: denial of service vulnerabilities
proftpd: remote root shell
rsync - remotely exploitable heap overflow
Multiple-use vulnerability in Safe.pm
sane-backends: several vulnerabilities
screen: privilege escalation
File overwrite vulnerability in tar and unzip
Multiple vendor telnetd vulnerability
vim - modeline vulnerability
zebra: denial of service vulnerability
Page editor: Jonathan Corbet
Kernel development Release status Kernel release status The current 2.6 kernel is 2.6.0. Linus released the second 2.6.1 release candidate on January 6 without an announcement; the (relatively small) list of changes can be seen in the long-format changelog. Previously, 2.6.1-rc1 (announcement, changelog) had been released on December 31. It included quite a few fixes, along with a couple of internal API changes (see below), the restoration of the old | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||