Leading items [LWN.net]

The Linux Core Consortium

November 23, 2004

This article was contributed by Joe 'Zonker' Brockmeier.

Last week, Conectiva, Mandrakesoft, Progeny and Turbolinux announced the creation of the Linux Core Consortium (LCC), a project to create a common implementation of the Linux Standard Base (LSB) 2.0. According to the group's press release, the LCC plans to create this implementation by the first quarter of 2005. In addition to the four member companies, several organizations issued public statements of support, including Red Hat, Novell, Sun, HP, Computer Associates, the Free Standards Group and Open Source Development Labs.

To get a little more information than was contained in the press release, we talked with Progeny's Ian Murdock, and touched base with Mandrakesoft's Gaël Duval and Novell's Bruce Lowry about the LCC.

According to Murdock, the key message is that the LCC is "first and foremost about making the LSB stronger." He noted that the LSB is useful, but "implementation standards are always more powerful than paper standards." He was quick to point out that there were several differences between the LCC and the failed UnitedLinux effort:

Unlike UnitedLinux, which was a separate company set up to manage a collaborative process...it's a loosely defined collaboration where partners have equal representation and devote roughly equivalent resources [to the project].

The LCC also isn't burdened with SCO as a member, which is a strong bonus in and of itself.

Murdock also said that the LCC is an important goal for Progeny as well. "We can address both our Debian and RPM customers with that common core, which is obviously why we're interested in extending to RPM as well." He also said it was "a shame" that so much attention is focused on the difference between RPM and Debian packages, and that he'd like to see Debian directly involved in the LCC.

We asked what it would take for another company to join the organization. Murdock indicated that the members were eager to have other companies join the LCC, and that they've invited Red Hat and Novell, but they haven't completely sorted out requirements. We asked Duval if there would be a monetary requirement for other organizations. He said no, at least at this time.

For now there is no monetary requirement, only an agreement to sign, but this could change, for instance to avoid company who join just to get free advertising while providing nothing in return. It's clear that we need only motivated members in the LCC.

Both Murdock and Duval made it clear that the LCC would also welcome non-profit organizations like Debian, and they were also looking at a way to allow participation from individual developers. Murdock said that the LCC would have "more to say in the coming weeks."

It's not going to be the case where we do all the work ourselves and drop it in the lap of the open source community and say "here you go." We have a strong desire to involve the open source community, but it's too early to say exactly what form that will take.

...we're trying to compliment existing efforts in the Linux Standards Base. The right way to go about that is to be open and inclusive, the end result will be nothing short of a Linux implementation standard built by the community and industry. If that's the result, then the result will be a Linux that is not owned by a single Linux company and that will be good for all involved.

Of course, the LCC would have a stronger position if the two biggest players in the industry were involved. While Red Hat and Novell have made polite noises about the LCC, they haven't committed to it. We asked Lowry whether Novell's public statement of support would translate into more concrete action with regards to the LCC. According to Lowry:

We've offered moral support to the LCC for what they're working toward, which is adoption of the LSB and standardization in the space to encourage Linux application development. We're not commenting at this point on whether we might ultimately join. It's something we'll keep an eye on.

We also requested comment from Red Hat regarding its intentions towards the LCC, but have not received a reply in time for this article. Murdock said he can think of reasons why Red Hat and Novell might not choose to participate:

I can think of some reasons why they might not want to do that [make the LSB stronger], namely that behind the words, that Linux standards are important, at the end of the day they're trying to build their own proprietary position which largely revolves around the ISV certifications that they have...I suppose that any hesitance on their part represents a sort of mismatch between what they're saying and what they're doing.

Many in the open source community were disappointed that the UnitedLinux consortium did not release a working product to the community. Instead, UnitedLinux was only available as source through the original vendors, rather than a working product anyone could download. Murdock said that the LCC would make available an installable version of the distribution that would be useful for developers, though he added it "won't be interesting to use on its own."

As Murdock noted, an implementation of the LSB 2.0 standard would be much more useful and powerful than the standard on paper. We're eager to see the LCC's first release, and hope this goes a long way towards increasing interoperability between Linux distributions and providing a unified platform for software vendors and open source developers to write to.

Comments (6 posted)

De-worming the net

Worms are a problem on the net. Even users of operating systems which tend not to be afflicted by this sort of malware are affected when worm-caused traffic clogs the net or brings down sites of interest. So everybody has an interest in finding ways to reduce the number of worm infections.

Researcher Douglas Barnes has taken a look at the problem and come up with a new set of recommendations. His work is written up in this 50-page PDF document. We took a look at his work, with an emphasis on its implications for the free software community.

The paper starts by pointing out that market forces have failed to put an end to the worm problem. Indeed, the characteristics of the software market tend to encourage the creation and use of vulnerable software. The company which wins in the market is the one which is able to get its product adopted first and establish the de facto standards. So manufacturers have a great incentive to emphasize features and time to market over security. Since moving away from buggy software can be difficult, software vendors tend not to pay much of a cost for security incidents which involve their products.

The author notes that free software is a pleasant exception to this problem:

Open Source software is often developed by, or with substantial participation from particularly security-conscious users. These users have strong incentives to participate in initial development in order to prevent having to rework the product later or create a more secure "fork." Open source does not directly address the problem of user flaws, and particular projects can be as rushed and buggy as proprietary software. However, because it is open and modifiable by anyone, it is at least capable of responding to those users who are concerned.

Some commenters (notably Bruce Schneier) have proposed that software vendors should be made legally liable for flaws in their products. At that point, they will have a strong motivation to take the time to get things right. Mr. Barnes, however, thinks that the liability approach will not work. Many quirks in the U.S. justice system make it hard to win a suit based on software flaws; these include the enforceability of "click-wrap" licenses, the notion that the vendor is not the real cause of security problems (the crackers are), and the interesting precedent that loss of data is not considered to be "physical harm." The potential harm to free software projects is also mentioned as a reason to avoid the litigation approach.

So how is the worm problem to be solved? Mr. Barnes has three suggestions:

Bug Bounties. The success of bounties offered to those who report security-related bugs in programs like Netscape and djbdns is remarked upon. Mr. Barnes notes, however, that software companies are generally uninterested in offering bug bounties. So, he says, bounties should be imposed upon them by way of a publicly-administered program. Software publishers would contribute to a fund which would be used to pay bounties.
Quality standards for software. The idea here is that worms should be treated as if they were an environmental issue; some sort of regulatory agency would be empowered to impose standards upon software. No suggestions for specific standards are made.
Penalties for use of insecure software. Users, this paper claims, do not sufficiently value security in software. To help them see the error of their ways, a penalty would be imposed on users who insist on running software known to be insecure.

Establishing this sort of regulatory regime looks like an uphill battle, to say the least. That is likely to be a good thing; the imposition of a heavy-handed, low-clue regulatory agency upon the software industry could easily do more harm than good. But the community can - and does - benefit from these ideas already.

Free software projects with the requisite funding have used bug bounties before; the original such bounty may well have been Donald Knuth's rewards to those who found bugs in T_eX. Even in the absence of cash bounties, numerous white-hat researchers can be seen digging for security bugs in free software for the reputation benefits and the sheer fun of it. Perhaps groups like OSDL could consider offering bounties on security bugs in certain bodies of code as a way of encouraging this process.

Free projects often have software quality standards as well, though they vary greatly from one project to the next. Peer review can help to find any of a number of obvious mistakes; in some projects, code is increasingly unlikely to be accepted if it is not seen as being up to certain standards. Many project could benefit from stronger standards, however, and from some sort of documentation of just what their standards are.

The community has little sympathy for penalizing users for their software choices, certainly. Still, that approach can be seen in some corners. Firefox will nag at people who use a version known to have vulnerabilities. Hopelessly insecure packages become unsupported and unavailable from distributions, forcing users to find an alternative. But the community has put most of its effort into an alternative approach: making it as easy as possible to run a system without known vulnerabilities. Most modern distributions can be kept updated with little or no effort; it's almost harder not to patch them.

So, perhaps, the free software community already has most of the tools it needs to contribute toward a worm-free net. No regulatory action required. All that is needed is to get the rest of the software community to catch up.

Comments (14 posted)

A followup on comment policy

Last week, we posted a request for comments on a proposed policy change which would limit comment posting privileges to paying subscribers. One should not post an RFC if one is not prepared to get comments; we got over 150 (at last count) of them. As a result of our reading of these comments, the proposed policy change will probably not go into effect.

While a wide variety of opinions was posted, there seems to be something close to a consensus on two points:

The problem of noise posts on LWN really is not all that bad. Not yet, at least.
The non-subscribing posters have worthwhile things to say, and there are numerous readers who have legitimate reasons for not subscribing.

The overall sense we got from the posted comments is that silencing the non-subscribing commenters is an overreaction to a small problem and not warranted - or desirable - at this time. So we will not do it.

There were various alternative ideas posted, some of which we will likely act upon in the relatively near future. These include:

Marking comments in such a way that makes the subscription status of their posters evident. This one is easy and will likely be done.
Add optional filtering capabilities for subscribers, making it possible to hide comments from specific people, or from non-subscribers in general.

There have been suggestions for active moderation of comments. Frankly, the editors of LWN have no time for, or interest in, running any sort of comment approval process. That process would be no fun at all, and there would be no way to do it without coming across as censors. Active moderation of comments can also increase the risk of legal hassles resulting from defamatory or infringing comments.

Moderation by LWN's readers has also been raised as a possibility, though not everybody likes that idea. We could consider the introduction of a reader moderation or recommendation scheme, but that is likely to be further in the future. The programming requirements are higher, and our current server would be unlikely to handle the additional database load in any sort of graceful manner.

Some other suggestions have been made. One was to publicly reveal the real-world identity of abusive posters. Problems with that approach are (1) we do not require readers to provide us with that information, and (2) even when we have it, revealing it would violate our privacy policy. We take that policy seriously, and will not be compromising it. Another idea was simply revoking comment privileges from abusive posters. The problem there is that, as long as LWN accounts are free, a blocked poster can simply create a new account and start over.

This has been an interesting exercise, anyway. In the end, LWN exists for its readers; if we do not serve your needs, there is little point in our being here. So we greatly appreciate the time you all have taken to provide feedback on our ideas. Rest assured that this feedback has been heard, and that we will continue to work to make LWN the best that it can be.

Comments (46 posted)

Page editor: Jonathan Corbet
Next page: Security>>