User: Password:
Subscribe / Log in / New account Weekly Edition for April 13, 2006

How Mono got into Fedora

Back in January, Red Hat reversed a longstanding policy and allowed the Mono .NET implementation into the Fedora distribution. A set of Mono applications (Tomboy, Banshee, F-spot) also went in at that time. The move was generally welcomed, but a number of observers wondered what had changed to make the addition of Mono possible. The sticking point had been a set of patents on .NET held by Microsoft; presumably those patents were no longer seen as a threat. But no information on why that might be was released at that time.

We missed it at the time, but Fedora hacker Greg DeKoenigsberg posted an explanation in late March. The answer, as it turns out, may offer some clues of how the software patent battle might play out.

Back in November, the Open Invention Network (OIN) announced its existence. OIN is a corporation which has been set up for one express purpose: to acquire patents and use them to promote and defend free software. The OIN patent policy is this:

Patents owned by Open Invention Network will be available on a royalty-free basis to any company, institution or individual that agrees not to assert its patents against the Linux operating system or certain Linux-related applications.

The list of "certain Linux-related applications" is said to exist, though it has not, yet, been posted publicly. But Mono is apparently on that list. So anybody who files patent infringement suits against Mono users, and who is, in turn, making use of technology covered by OIN's patents is setting himself up for a countersuit. Depending on the value of the patents held by OIN, that threat could raise the risk of attacking Mono considerably.

That last sentence is important: a potential OIN countersuit will only have a deterring effect if OIN's patents cover an important technology and look like they would stand up in court. As it happens, OIN holds a set of patents covering a number of fundamental aspects of XML-based web services. These patents (originally assigned to a failing company called Commerce One) created a fair amount of concern when they went up for auction at the end of 2004; many companies feared that they could be used to shake down companies all over the e-commerce field. What actually happened is rather different: they were bought by Novell for $15.5 million and eventually contributed to the OIN pool. These patents, it seems, are considered strong enough to keep Mono safe.

Novell did the community (and perhaps the technology industry as a whole) a big favor by buying those patents; in the process, it beat out bids from a couple of "intellectual property" firms associated with Nathan Myhrvold. Donating them to OIN multiplied the favor by putting these patents directly into the service of free software. We may all be a little safer as a result of this action.

Some observers in the community have criticized the patent pool idea in the past. Playing the software patent game in any way is a little distasteful, and it is not clear to everybody that the owner of the pool would have the standing or interest to defend the target of a patent attack. The true success of OIN can only be judged in the long term, and, in the best case scenario (no software patent suits are ever brought against free software users), its contribution will never be entirely clear. What is clear, however, is that OIN has already brought some peace of mind to some of the people who were most worried about the software patent threat. That seems like a step in the right direction.

Comments (14 posted)

Fear of a Linux virus

There can be no doubt that the folks at Kaspersky Lab are persistent. Back in 1999, Kaspersky released its anti-virus product for Linux; the company also claimed to be preparing "the world's first Linux-based rescue disk." In 2000, the company claimed that "new viruses for Linux appear every day," though it backed down when that claim was questioned. Now Kaspersky claims to have encountered a "cross-platform virus," which is capable of infecting both Linux and Windows systems. Time to be worried:

The virus doesn't have any practical application - it's classic Proof of Concept code, written to show that it is possible to create a cross platform virus. However, our experience shows that once proof of concept code is released, virus writers are usually quick to take the code, and adapt it for their own use.

There is hope, however: worried system administrators need only purchase Kaspersky's anti-virus service, and they will be protected from the threat of this new cross-platform virus.

Strangely enough, Linux administrators have somehow managed to avoid going into a panic over this announcement. In fact, few Linux users feel any more threatened than they did before.

This new "virus" is a program which is able to inject its code into executable files found in the current working directory. It can't be the first code with this capability - that particular problem is not especially hard to solve. Given write access to an executable file, a program can write to that file. If it is coded to write something unpleasant, that is what will happen.

What this "virus" appears to lack is any sort of propagation mechanism. If somebody runs it, their executable files will be corrupted, but it has no way of traveling further. Any attempt to add propagation to this code will run into some well-known problems: (1) getting Linux users to run random malware is still challenging, and (2) most Linux users lack the access to modify most of the executables they run, most of the time. The normal protection mechanisms designed to keep users from accidentally (or maliciously) damaging their systems will also serve to impede any attempt to infect those systems.

One should not say that writing a rapidly-propagating, Linux-based virus or worm is not possible. Sooner or later, somebody will probably pull it off. But any such malware will have to exploit an open security vulnerability in the target systems, and any vulnerability which is exploited in this manner will be closed in a hurry. Commercial anti-virus products work by trying to keep threatening malware away from the system altogether. The Linux way of doing things, instead, is to make the system resistant to the attack vector used by the malware in the first place. Security updates may propagate a little more slowly than virus descriptions, but the end result will tend to be far longer-lasting.

So it is not clear that there will ever be a real market niche for anti-virus products on Linux systems. Linux administrators prefer to fix the root problem, and most distributors have well-tuned mechanisms in place for making those fixes quick and easy. Anti-virus products add complexity to a system, can create problems of their own, and may well not be any more effective against any sort of "zero-day" attack. If, in the future, we find ourselves truly needing anti-virus software, our development process will have failed badly. Chances are that we will not fail in that way, but the flow of scary press releases from anti-virus companies will certainly continue regardless.

Comments (14 posted)

Some distribution disagreements

Back when Red Hat Linux was a product delivered by Red Hat Inc. in its final form, the user community had little visibility into the decisions that affected the distribution. One of the early promises that came with the Fedora Project was that the important discussions would happen in a public forum. Things have not always happened that way, and a number of things still seem to happen by anonymous decree. It is true, however, that the public discussion has grown more vibrant as the wider Fedora community insists on having its say.

One recurring discussion has to do with one of those decisions by decree: Fedora Core 5 lacks the "install everything" option which has characterized Red Hat releases for many years. The reasons behind this change make some sense: it is increasingly hard to support as the distribution grows, and as the distribution is split between "core" and "extras." Some packages conflict with others, making a true "everything" install impossible in any case. Installing everything is an invitation to unnecessary security problems. And the Anaconda installer has been reworked around a yum-based backend which is not so well equipped to do "everything" installs in any case. Administrators who do a lot of "everything" installs can use kickstart to obtain something close to the old behavior.

So removing this option was not an unreasonable thing to do. But the community was not involved in the decision, and quite a few Fedora users are most unhappy with the change. Since there was no discussion - not even an announcement of the change - these unhappy users continue to fill the Fedora lists with complaints; it is beginning to look like one of those threads which never really goes away. But, "install everything" has gone away, and appears highly unlikely to return.

A more relevant discussion, perhaps, is this one: what is to happen with evolution in Fedora Core? The state of the FC5 evolution package is evidently so poor that some Red Hat developers are suggesting that it should be shoved out to Fedora Extras, or dropped altogether:

Evolution in extras is a bad idea. Evolution in core is a worse idea. What other as good as unmaintained large buggy package exposed to external attack and with known unfixed DoS bugs (and probably worse yet to be found) do we ship.

Evolution belongs in the bitbucket.

(Alan Cox).

The state of evolution is a bit of a problem. It has been pushed for some time as the mail user agent for Red Hat and Fedora systems; it is also the only mail client with its particular combination of email and calendar features. Quite a few Fedora (and RHEL) users depend on it heavily. So the chances are that evolution is not truly destined for the bit bucket.

There appear to be two issues here. One is that the core evolution project has been on hold for some time. There is a new set of developers working on evolution, and there are signs that the process is beginning to move again - though some observers are not yet convinced. The other issue is that the evolution package within Fedora is unmaintained, and has been for some time. This is a different sort of problem: Red Hat is actively trying to hire somebody to maintain the evolution package, but has not yet found anybody. Until that position can be filled, the evolution package in Fedora is likely to continue to languish.

An interesting side note on this discussion is that some participants have complained about Red Hat engineers suggesting the removal of Evolution. It seems that Red Hat folks have a duty to not scare the users that way. But the truth of the matter is that we cannot have it both ways: if we want to have a vibrant and open Fedora development community, the engineers involved must be able to speak their minds.

Meanwhile, the Ubuntu community has run into a different sort of issue. The original Ubuntu distribution was very much GNOME-based, with a KDE-based version ("Kubuntu") being somewhat of a second-class citizen. Last November, however, Mark Shuttleworth announced that Kubuntu would become "a first class distribution within the Ubuntu community." From the outside, it would appear that things have happened that way; Kubuntu releases happen at about the same time as "plain" Ubuntu releases, and Kubuntu has a large and (seemingly) happy user community.

As of this writing, however, visitors to the site are greeted with a protest message rather than the normal resources found there. It seems that some of the developers working on Kubuntu are not particularly happy with their relationship with Canonical. They do not feel that Kubuntu is, yet, a "first-class distribution."

The protest appears to be lead by Andreas Mueller, a co-founder of the Kubuntu project and the maintainer of Mr. Mueller is a volunteer Kubuntu developer, not currently on the Canonical payroll. There are a number of complaints being voiced, and it is not entirely clear what the real problem is. Discussion on the lists suggests that a misunderstanding over administrative accounts is part of it. The core, however, may well be this:

Kubuntu needs more paid developers. Even though Canonical says that there is one paid developer for GNOME and one KDE (seb128/jriddell), the rest of the paid developers rather tend to support GNOME. It would be reasonable to pay at least 2-3 more developers to balance, because only providing KDE-packages is not enough.

A cynical observer might be tempted to conclude that Mr. Mueller is trying to shame Canonical into hiring him.

It is hard to say whether Canonical is putting sufficient resources into Kubuntu or not. It is true that there has been no great outpouring of support for this protest on the Kubuntu mailing lists. Kubuntu users seem generally content with their lot. Hopefully this disagreement can be resolved without changing that situation.

Comments (31 posted)

Page editor: Jonathan Corbet

Inside this week's Weekly Edition

  • Security: Cross-site scripting attacks; New vulnerabilities in clamav, mplayer, openvpn, plone, ...
  • Kernel: Containers and lightweight virtualization; tee() with your splice()?; Wireless networking summit report.
  • Distributions: A Quick Look at grml; FoX Desktop 1.0; DPL election results
  • Development: Review of the LINI PC, GNOME Goals, KDE Commit Digest, new versions of SQLite, BusyBox, Campsite, LyX, watermelons, Comix, KOffice, Indian Language OO.o, Phex, Speedometer, Mercurial, monotone, RODIN.
  • Press: Bruce Perens on the State of Open Source, dressing for success, coverage of FUDCon and LinuxWorld, Chinese antipiracy, Intel and Red Hat team up, Microsoft's Port 25, DNS Howto, iPodLinux, Photoshop plugins under the GIMP, LTSP 4.2.
  • Announcements: Red Hat acquires JBoss, EFF on Dragnet Surveillance, Netcraft Web Server Survey,Firefox Flicks, Atlanta Desktop Linux Printing Summit coverage, Black Hat CFP, LinuxWorld videos.
Next page: Security>>

Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds