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
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
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
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
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
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)
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
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
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
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 TeX. 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
Comments (14 posted)
Last week, we posted a request
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
Comments (46 posted)
Page editor: Jonathan Corbet
Next page: Security>>