Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for May 10, 2007Episodes from the evolution of Fedora The Fedora 7 release, due on May 24 (though it appears that schedule may slip a bit), marks the beginning of a new era for this distribution. As that release approaches, a number of issues have come up which merit some attention. Here's a review of some events in Fedora land.One of the core developments in Fedora 7, so to speak, is the merging of the "Core" and "Extras" distributions. As of the next release, it is all simply "Fedora." Given the nearness of the release, one would have thought that this merger would have happened some time ago. As it happens, that merger is just being finished up now. Much of the ground work was done over the preceding months, leading up to the actual joining of the repositories, source management subsystems, and build systems happening now. As of this writing, the new source archives and build systems are up, but the flow of packages into the Rawhide distribution has not resumed. There has been a small amount of concern voiced by a few maintainers of packages formerly found in Extras. In the good old days, they could post an updated package at any time and have it go right into the repository. Now that there is only one repository, the whole thing is currently frozen in the run-up to the release. How to work in the new, unified environment is still not entirely clear to all Extras package maintainers. Overall, though, the number of glitches from the merger appears to be small - so far. More information can be found in the draft post-merge FAQ. Red Hat's distributions have long been known for including software which is not necessarily completely mature. Over the years, this company has pushed in bleeding-edge technologies like ELF binaries, glibc2, SELinux, and more; the end result has often been a combination of user pain and accelerated development of the code in question. Fedora is in many ways the true descendant of Red Hat Linux, and it continues the practice of packaging very new technologies. Some users are beginning to wonder if that practice has gone just a little too far this time, though. The software in question is the Nouveau driver. This reverse-engineered code is an eventual replacement for the binary-only drivers supplied by NVIDIA. Someday, Nouveau will be the driver of choice for people with NVIDIA hardware, but today is not that day. The Nouveau driver is still in heavy development with a lot of problems to solve before it is ready for production use. But Fedora 7 includes it anyway so that people with an interest in trying out the new driver can do so. Fedora 7 does not enable Nouveau for any system unless explicitly told to. In theory, anybody who turns it on should know what they are getting into; in practice, at least one user has already been burned by trying Nouveau in a situation where it did not work. So some voices have been heard to say that Nouveau has been included ahead of its time and should be removed. Fedora developers still want to include it, though:
It is turned off by default just like the new Intel xorg driver in
FC6. That did help in users providing feedback when they turn it on
manually. It fits our mission of progressing Free software. This is
a important project. Anything that we can do to help is worth the
effort.
Others say that a project as important as Nouveau should not be subjected to a tide of disappointed users who were lulled into trying the code before its time by their distributor. Chances are that Nouveau will remain. There is one remaining issue, though: Nouveau is currently co-packaged with the stable "nv" driver that people are actually expected to use. So Nouveau cannot be updated without pushing out a new nv package. Given that Nouveau can be expected to evolve considerably over the life of Fedora 7, impediments to the packaging of updated versions seem like a bad idea. There is talk of splitting Nouveau into its own package, which seems like a more than reasonable way of solving this problem. Finally, there is the issue of Python 2.5. That is the current version of the language, and the version which will be shipped with Fedora 7. The only problem is that the Zope content management system, which serves as the base for Plone (and others), does not work with this version of Python. So the current plan is for Fedora 7 to ship without Zope or the packages which depend on Zope. Back in the days when Red Hat Linux fit on a single CD, a core component like Python would not have been updated until everything which depended on it was ready for the change. In fact, Red Hat Linux was glacially slow to move to Python 2 for just this reason. Fedora is a much larger distribution which lacks the same sort of firm central control, so it has become much harder to delay an update like this. And, unlike Debian, Fedora is unwilling to delay a distribution release until all such issues are worked out. Some Zope users would like to see Fedora ship a "compat-python24" package so that Zope will continue to work. There is some opposition to this idea, though:
As the python maintainer, I am *STRONGLY* opposed to a
compat-python24 package. Because at the end of the day, bug
reports will get filed against the wrong python package (because
end-users aren't going to know or case). Security problems are
still going to end up having to be dealt with and likely through me
because the CVE will originally get filed against python and no one
will think about compat-python.
Jeremy Katz, the maintainer quoted above, would like to see a rule allowing a package maintainer to veto the addition of older "compat" packages so that they could avoid having to deal with these sorts of problems. He seems likely to win this particular argument, meaning that there will probably be no Python 2.4 in Fedora 7. The implication is that interested people will end up creating a set of Zope and Python 2.4 packages for Fedora 7 and hosting them on a third-party server somewhere. It will be a small amount of extra hassle for affected users, but that can be worked around. The issue of security support (crucially important for a complex, network-facing system like Zope) should be considered by anybody wanting to run this code, however. There have been suggestions that the maintainer of the Zope package should undertake the task of making it work with the version of Python found in Fedora 7:
I believe very strongly that it _is_ the package maintainer's job
to work with upstream code to make it work with Fedora, and this
kind of thing _is_ a packaging issue.
There's a reason we have Fedora package maintainers instead of just automatically pulling in upstream tarballs and building them with rpmbuild -ta. It's because the role of the package maintainer is to make the package a _part_ of Fedora -- that's what makes Fedora a coherent distribution and not just a semi-random collection of packages. In this view, making Zope work with Fedora's version of Python is much like making it work with SELinux or Fedora's init scripts setup - just part of the job of making a package for the distribution. Once again, this role was probably easier to carry out back in the single-disk days. In any case, the current Fedora Zope maintainer is not going to port Zope to Python 2.5 - that is apparently a rather large job. This, too, will pass, and Fedora 8 may well be able to welcome Zope back into the fold. In the mean time, though, the Fedora developers are trying to figure out just how their distribution should react to issues like this. As Fedora evolves and becomes more open to the community, it will have to better define its policies and set them down so that developers know what to expect.
A think tank's view of free software Back in early March, a company called the Olliance Group held a gathering of about 100 corporate manager types at a resort in California's wine country. This "Open Source think tank" has now produced a 16-page report [PDF]. It is, indeed, an interesting look at how a certain part of the corporate world views free software - though, perhaps, not entirely in the ways its authors intended.When a self-appointed "think tank" gets together to talk about free software, one is right to be cautious. When one of that event's top-level sponsors is Microsoft, an extra degree of nervousness seems appropriate. The other top-level sponsor, naturally, is Novell; the remainder of the list is NEC, Unisys, Jasper Soft, OpenLogic, and SugarCRM. Not the most community-oriented bunch one could have come up with. LWN readers will be glad to know that "Overall, the CIOs unanimously agreed that open source is viewed as a viable option in software procurement decisions for their companies." Once they made that admission, however, this group started to raise its complaints about open source, many of which could have come from the 1990's. The first was lack of support - evidently there still is not enough commercial support for open source software. The report notes that "this is something the open source industry will have to address to increase adoption by companies." One would think that if there is truly a need for more support these companies would see that need as a business opportunity rather than an obligation. Another problem, it seems, is interoperability:
CIOs desire greater interoperability built directly into open
source products. This is an area where proprietary solutions
maintain an advantage over open source, as it is far easier to
integrate and use a suite of proprietary applications that are
guaranteed to interoperate and that have common interfaces that
make it easier for end-users to learn and use the suite.
This is a surprising claim, given that free software developers generally work toward interoperability with everything. The next claim is just as surprising:
Open source lacks compliance with many standards when compared with
proprietary solutions. These standards include universal standards
such as ISO, and industry-specific standards (financial industry
standards, health care industry standards, etc.). It was
acknowledged however, that open source offers some advantages in
the area of technology standards through its openness and
transparency and its ability to facilitate the creation of de facto
standards such as Eclipse and ODF.
The description of OpenDocument as a "de facto standard" borders on the dishonest. The various reasons why certain "industry standards" may not be supported as well as others are not examined. Think tank attendees bemoaned the fact that monetizing open source remains challenging. Then, there is this problem:
Open source generally
depends on a corps of motivated volunteer developers to develop
features. Often, the features that developers are interested in
working on are different then features that customers are
requesting. For example, Openoffice customers want more Visual
Basic macros to ensure interoperability with Microsoft Office, but
OO developers have not been all that interested in building VB
macros.
The idea that a company whose business model depends on better VB support could devote resources to the creation of that support is not mentioned anywhere in the report. Licensing is an issue which is mentioned several times in the report:
Open source licensing is a big source of confusion due to the
number of open source licenses, and a lack of understanding on how
licenses impact business, as well as how licenses interact with one
another. Some licenses require technology to be shared with the
community, other licenses require attribution, and numerous
licenses have different ways of dealing with software
patents. Furthermore, many licenses are incompatible. License
proliferation, confusion and incompatibility are barriers to the
continued growth and adoption of open source.
Clearly, we would be better off with the simplicity, compatibility, and fairness found in proprietary software licenses. Beyond that:
Think Tank participants bemoaned the lack of a business-friendly
license that adequately addresses issues such as copyright,
patents, attribution and indemnification. While nobody was
suggesting "yet another license" as the solution, the
dissatisfaction by commercial vendors and customers with the
existing licenses was clear.
It would be most enlightening to see what this "business-friendly license" would involve, but the attendees apparently ran out of time before they could elaborate on that point. The GPLv3 draft was also discussed, with a generally negative response. Another problem:
These issues also point to the need for better governance of open
source contributions. Currently, projects have many different
standards governing code contributions - some communities
vet the code, some require contribution agreements to be signed and
others have no such requirements. The lack of standards and
governance on contributions raises concerns on the source and
legitimacy of code that is incorporated into projects.
This is a claim that needs to be backed up: despite the intense attention which has been given to the provenance of code in a number of high-profile projects, the number of real problems has been exceedingly small. If the attendees of this think tank wish to claim that the code found in free software projects is less likely to be legitimate than proprietary code, they need to come up with some evidence to that effect. Sadly, space constraints appear to have prevented this evidence from being included in the report. Other worries include a lack of open source developers - their numbers are not keeping up with the growth of the industry. The fact that quite a few developers are coming out of universities is considered to be a good thing, but not without reservations: "However a concern was expressed that due to the popularity of open source development at universities, graduates may be lacking key skills such as sound architecture, defining customer needs and product management." We also hear that open source "tends to fragment easily," presenting problems for vendors. "Commercial open source tends to be less fragmented, while 'pure' open source tends to be more fragmented." All is not bad, though. Open source offers "flexibility in procurement" and "flexibility in deployment" where "companies can mix and match open source software as they please" - despite all of those interoperability and standards compliance problems we heard about earlier. Faster product cycles are seen to be good, as are faster bug fixes. Plus:
In addition, there is "perceived" value in the ability to fix or
enhance open source code at the CIOs pleasure even if the vast
majority of user organizations do not .
This "perceived" value is as close as this report ever gets to any sort of freedom-related issue. There is plenty more to look at in this report, but perhaps it is best to finish with this observation:
Finally, OSS and proprietary models continue to converge.
Proprietary companies are taking elements of the open source model,
including faster development cycles, and free, downloadable trial
versions. OSS companies are taking elements of the proprietary
model, by offering support, updates and indemnification.
This report gives no space to the developers of all this software, beyond complaining that both their numbers and their motivation to implement Visual Basic macros are insufficient. There is no thought toward maintaining healthy development and user communities, addressing problematic legal issues, or contributing back to the community in any way. These are people who see free software as a well from which they can draw resources for their businesses, but that software is just a raw material. They want to repackage and sell that material in as proprietary a manner as possible. If this group represents the future of the open source business community, we could be in real trouble. A look at the list of sponsors given at the top of this article is cause for comfort, however, as most of the companies which have found real success with free software chose not to support this event. So there is reason to believe that this "think tank" is not representative of the wider business community, that, instead, it's a group of leaders of businesses who wish they were doing better at "monetizing" free software.
The Grumpy Editor's next project
Chances are, however, that many of those companies share the one exception which can be found here at LWN: our business accounting is done using a well-known, proprietary, small business bookkeeping tool. It has all the problems associated with such tools: it holds our company data in an opaque, proprietary format, it does not interoperate with the rest of our operation, it does not work as reliably as we would like, and it occasionally forces an expensive upgrade to a new version for no clear reason. Plus there's that proprietary operating system that the bookkeeping application depends on. Various attempts to replace this application have failed to take off. It's hard to replace a functioning, important business subsystem, and, frankly, free alternatives in the business accounting area have been slow to reach a mature state. Your editor has recently become determined to change this situation, though. Enough is enough. A new accounting system will have to meet a number of needs. To begin with, it must be able to import accounts and historical data from the proprietary application. It should operate in a multi-user, network-friendly manner. We need all of the usual accounting functions, from double-entry bookkeeping to easy export of data to our accountant to the creation of the occasional pie chart. And we would really like the ability to integrate it with the LWN site code, since so much of our commerce goes through that code. There are numerous projects in this space. Your editor's list of candidates at the moment includes (in no particular order):
As one can see, there is no shortage of alternatives to look at; no doubt LWN readers will know of a few which your editor missed. Working through this list will be more than enough to keep an editor busy for some time; since your editor has no particular passion for accounting, it's also likely to make him somewhat grumpier than usual. It's clearly not a topic which can be covered in a single article. So expect a series of installments as your editor heads into the accounting jungle and tries to figure out whether it's possible to run a business completely on free software or not.
Page editor: Jonathan Corbet Security Stability v. security fixes A whole pile of security fixes for Red Hat Enterprise Linux 4 (RHEL4) was released at the beginning of May; this event might not be noteworthy except that some of the vulnerabilities were nearly two years old. This stands in contrast to a recent Red Hat article describing the security track record of RHEL4, which was covered on this page, and made no mention of delays of this sort. Digging in a bit deeper to try and understand why seems logical. Of the thirteen fixes listed by LWN for that day, eleven are categorized as having low severity by Red Hat, one is moderate and one is important. The latter is a recently reported vulnerability in xscreensaver that was given a CVE number less than a month ago. Of the dozen others, eight had CVE numbers from 2006 and four from 2005. Red Hat classifies security issues based on their analysis of their impact; both "low" and "moderate" vulnerabilities are unlikely to be exploitable, with "moderate" vulnerabilities having worse consequences if it does happen. Under those definitions, it would certainly seem less important to get those fixes out, but it would also seem like a headache to keep track of them. Fedora Core released fixes for these issues ages ago and those seem to have worked out, why did Red Hat sit on them for RHEL4 for so long? Mark Cox, from the Red Hat Security Response Team explains:
So for example CVE-2005-4268 relies on an attacker giving a victim a
carefully crafted rather large cpio file, and getting the victim to open
it using the cpio command on a 64-bit platform. Even if the attacker
manages that, the ability to lead to code execution is unlikely. So we
defer these issues; customers don't want to go through an update and test
cycle just to fix such an issue. Then, when other issues of a higher
severity come up in the same package, or if we are to release an update
to that package for any other reason, we also pick up any fixes we
previously deferred.
Red Hat Enterprise Linux errata are batched into periodic 'updates'; what was released this week was Update 5 for Red Hat Enterprise Linux 4. So, for low and some moderate impact bugs, RHEL4 users must wait for patches until some other issue with that package requires attention and then await the next batch of fixes as an update release. An intervening update cycle is not necessarily enough to push these fixes out as there have been several update releases to RHEL4 since they were reported. RHEL customers prize stability, and delayed security updates is part of Red Hat's process for delivering that stability. Security issues (and bugs in general) are funny beasts and sometimes their implications do not become clear for a long time. Something that seems to have a low impact is suddenly used in an unexpected way by a worm or some other exploit and the impact needs to be recalculated. By holding back these fixes for seemingly trivial security issues, Red Hat could be setting itself up for an unpleasant security surprise someday. Some customers may also feel that they are more at risk for a particular issue than Red Hat thinks they are. Perhaps they use cpio frequently on possibly untrusted data on their 64-bit machines. As things currently stand, they had no fix available to them (at least via the normal Red Hat update means) for more than a year; there was no easy way for them to even know there is a problem. Red Hat tracks these bugs via bugzilla which is open for anyone to use, but they only put out announcements when they release a fix. It is hard to argue that customers should be trolling security lists and/or bugzilla looking for security issues that might affect them; this is, after all, what they pay Red Hat for. As with seemingly everything in the world of computers, there is a trade-off here; very few customers would want to be upgrading their production systems frequently for low impact bugs. On the other hand, they may not want to be exposed forever to those same low impact bugs. Batching these kinds of fixes up into security updates once or twice a year seems like a reasonable plan, but holding on to updates for over a year may be just a bit more stability than some customers were looking for.
New vulnerabilities dovecot: directory traversal
elinks: code execution
gimp: symlink issue
ldap-account-manager: privilege escalation, possible cross-site scripting
lftp: shell command execution
moin: arbitrary JavaScript execution
php: several vulnerabilities
pop mail man-in-the-middle attacks
pptpd: denial of service
python: information disclosure
tetex: buffer overflow
Updated vulnerabilities aircrack-ng: remote execution of arbitrary code
apache: cross-site scripting
Asterisk: two SIP denial of service vulnerabilities
bluez-utils: hidd vulnerability
bugzilla: multiple vulnerabilities
busybox: insecure password generation
capi4k-utils: buffer overflow
clamav: several vulnerabilities
cpio: arbitrary code execution
cups: denial of service
Cyrus-SASL: DIGEST-MD5 Pre-Authentication Denial of Service
dovecot: index cache file handling error
evolution: format string error
fail2ban: denial of service
ffmpeg: buffer overflows
file: denial of service
file: arbitrary code execution
firefox: FTP PASV port-scanning
freeradius: memory leak
freetype: integer overflows
gcc: file overwrite vulnerability
gd: buffer overflow
gdb: buffer overflow
gdm: improper file permissions
gimp: arbitrary code execution
gzip: multiple vulnerabilities
horde-kronolith: local file inclusion
ImageMagick: integer overflows
imlib2: arbitrary code execution
ipsec-tools: denial of service
java: multiple vulnerabilities
kdelibs: cross-site scripting
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||