| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for August 23, 2007A pair of acquisitions While much of the commercial world was watching the initial public offering of VMWare stock, a competitor was carefully pushing forward a different strategy. On August 15, Citrix announced its acquisition of XenSource, the company formed to commercialize the Xen hypervisor. At $500 million, it is a pricey purchase - Citrix guesses that XenSource will bring in $50 million in revenue in 2008, but at a cost of $60-70 million. So profits from XenSource, in the near term, will be virtualized as well; perhaps the plan is to make it up in volume.Those who fear that money cannot be made with free software might take comfort in a half-billion dollar acquisition of a free software company. Of course, XenSource is far from a pure free software operation. The kernel-level code is GPL-licensed, as is required; much of that code has recently, after a long delay, found its way into the mainline kernel. But the upper layers - the code for the management of virtualized systems - is highly proprietary. It is offered in a three-tier scheme, with the more expensive products un-crippling larger numbers of features. These products are where the revenue comes from. This acquisition is somewhat indicative of what is happening in the virtualization market. The low-level functionality is free, and is getting steadily more capable. But the tools for the administration of virtualized systems - a task of daunting complexity for sites running large numbers of virtual guests - are generally proprietary. It is the offerings at this level which give XenSource its value despite the fact that Xen's kernel-level support is increasingly surrounded by capable and arguably better-designed alternatives. For all practical purposes, the XenSource acquisition is just the purchase of yet another proprietary software company, Xen's free software origins notwithstanding. Perhaps more interesting is the acquisition of the ClamAV project by Sourcefire, the company behind the Snort intrusion detection system. ClamAV, a virus scanner, is a true free software project which, previously, had lacked a commercial component. Details have not been disclosed, but one assumes that the owners of ClamAV did not make out quite as well as the holders of XenSource stock. They did get jobs out of the deal, though; they will now continue their ClamAV work as Sourcefire employees. Who the owners are is, in this case, an interesting question. Projects led by developers with commercial ambitions typically require copyright assignments for any outside contributions. With ownership of 100% of the code base, selling a project (or taking it proprietary) is a relatively straightforward operation. ClamAV, however, is not one of those projects, and all contributors retained their copyrights. So Sourcefire does not own the entire ClamAV code base (or the equally important virus signature database). What it has acquired is the copyrights held by the primary contributors - a large part of the project, but not the whole thing. This ownership structure could be a bit of a challenge for Sourcefire going forward; part of the plan for making money from this deal involves making a commercially-licensed version of ClamAV available for vendors who wish to integrate ClamAV into their products without being bound by the GPL. To make this offering possible, Sourcefire will be digging through the code and the source code management system to weed out any code which it cannot relicense. If the developers involved have an accurate idea of how much code is involved, if they are thorough in eradicating it, and if they do not anger any outside contributors to the point that they wish to create trouble, this scheme could go well. If a misstep is made somewhere, the possibility of legal action and other unpleasant consequences is very real. For now, the stated plan is to continue to keep the entire code base and signature database available under the GPL. Sourcefire's Mike Guiterman says that the ClamAV user community has nothing to worry about:
In this case our (Sourcefire's) track record with Snort speaks for
itself. Sourcefire has never with held or delayed a feature in
Snort from the open source community. Snort releases and Sourcefire
commercial releases are in lock step.
It has been pointed out, though, that there is a bit more to Sourcefire's track record than stated above. Snort releases may happen "in lock step," but anybody who has not bought a Snort rules subscription must wait 30 days for rule updates. Like Snort, ClamAV uses a frequently-updated set of rules which are compared against incoming traffic to detect threats. So it would seem that the ClamAV signature database would be very much amenable to the same commercial treatment; that is, after all, how a number of other anti-virus companies do business. For now, though, all of the indications are that Sourcefire will not be creating a subscription service around ClamAV signature updates. Quite possibly the company feels that one reason for ClamAV's success is the presence of a wider community which can contribute those updates; putting signature updates behind a subscription gate would almost certainly cause community contributions to dry up. Rather than risk damaging the project it just bought, Sourcefire may have decided to seek revenue in other directions - for now, at least. With sufficient care, Sourcefire should be able to keep the ClamAV community together - and, perhaps, help it to grow further. Acquisition of a free software project is almost certain to bring change, but that change need not be bad. As we head steadily toward World Domination, we may well see more of these deals. One can only hope that the companies carrying out these acquisitions understand well that, in the absence of the wider community, all they can acquire is a lump of code. Preserving the value of a project acquisition requires preserving the community that goes with it. As long as this important fact is kept in mind, acquisitions can be ultimately beneficial to the affected projects and free software as a whole.
Large projects and decentralized development Development using Git, with its decentralized model, is gaining proponents for projects beyond its Linux kernel heritage. Some recent threads on the kde-core-devel mailing list have been discussing how Git might be used by some developers without disrupting the Subversion (svn) infrastructure that is used by KDE. That conversation has broadened to consider how a large project like KDE might reorganize to take advantage of Git's strengths. It does not look like KDE is really considering a switch – they converted from CVS a little over two years ago – but the discussion is useful to anyone thinking about using Git. There are really two separate discussions taking place, the first concerns using Git without disrupting svn, while the second covers the larger issues of how to structure and use Git for a larger project. The two are intertwined as the "best practice" for a KDE-sized project is to convert incrementally. Smaller sub-projects, a particular KDE application for example, would use Git while still committing the changes back to the svn repository. Trying to do a wholesale conversion of a project the size of KDE, with many developers, testers, translators and users – not to mention millions of lines of code – would be something approaching impossible. For tracking an svn repository, while using Git locally, the git-svn tool is indispensable. It uses any of the svn protocols to check out a repository, optionally including branches and tags, and installing them as a Git repository. A developer then uses Git commands locally, using git-svn again when ready to update from or push changes to the svn repository. It is not a perfect fit, complaints about losing history in the conversion have been heard, but it does provide Git users a way to interact with svn. The decentralized nature of the Git development model is always a stumbling block for projects that are used to the single, central, repository model of svn and other revision control systems. Adam Treat invited a rather well-known expert on Git, with some small experience in applying it to large projects, to comment on some of the questions he and others had. Linus Torvalds, who is also a KDE user, responded, at length, with some very useful insights. Breaking the project into sub-projects is the first step:
So I'm hoping that if you guys are seriously considering git, you'd also
split up the KDE repository so that it's not one single huge one, but with
multiple smaller repositories (ie kdelibs might be one, and each major app
would be its own), and then using the git "submodule" support to tie it
all together.
Using the git-submodule command, a project can be broken up into many pieces, each with their own Git repository. Those separate repositories can then be stitched together into a "superproject" that understands how to handle a collection of repositories. If a change affects multiple modules, it can still be handled in an atomic way:
What happens is that you do a single commit in each submodule that is
atomic to that *private* copy of that submodule (and nobody will ever see
it on its own, since you'd not push it out), and then in the supermodule
you make *another* commit that updates the supermodule to all the changes
in each submodule.
See? It's totally atomic. Anybody that updates from the supermodule will get one supermodule commit, when that in turn fetches all the submodule changes, you never have any inconsistent state. Users of a development tree have differing needs, which Git supports by not requiring a central repository that all users must interact with. Torvalds believes that the development organization, not the tool, should determine which repositories are central:
I certainly agree that almost any project will want a "central" repository
in the sense that you want to have one canonical default source base that
people think of as the "primary" source base.
For Linux, his kernel Git tree is the center, but for a variety of other
users, the "stable" tree or distribution kernel trees for example, their
repositories are the source. Those repositories can and do update from
time to time from the main tree, but they control when and the users of
those trees don't have to care.
But that should not be a *technical* distinction, it should be a *social* one, if you see what I mean. The reason? Quite often, certain groups would know that there is a primary archive, but for various reasons would want to ignore that knowledge. On the subject of mapping the current KDE practices to Git, Torvalds is, characteristically, not shy about expressing his opinion:
Hey, you can use your old model if you want to. git doesn't *force* you to
change. But trust me, once you start noticing how different groups can
have their own experimental branches, and can ask people to test stuff
that isn't ready for mainline yet, you'll see what the big deal is all
about.
Centralized _works_. It's just *inferior*. There is a clash of development models going on and Torvalds is pushing the kernel's model. His reasons are good, though they may not convince everyone, which is why Git tries hard to avoid forcing any particular style. As he did with open source development, Torvalds is trying to lead by example, while not forcing anyone to change. Reading the full threads including the entire posting by Torvalds will be very interesting to those who follow source code management issues. This culture clash, centralized and somewhat bureaucratic versus decentralized and freewheeling will come up again and again over the next few years. Torvalds seems to think the Git model will work most everywhere and his track record for making smart choices is good. It will be interesting to watch.
Microsoft's licenses: excerpts from a conversation Microsoft recently submitted two licenses to the Open Source Initiative to be considered for approval as being truly open source. There have been a few themes which have come out of the subsequent discussion. One is that the licenses are generally seen as being compliant with the Open Source Definition, though their incompatibility with other licenses bothers a few people. Not everybody agrees that the Microsoft Permissive License (MS-PL) is truly "permissive," and some have asked for a name change. There have been some grumblings that the licenses offer no additional value in a time when the OSI is actively trying to reduce license proliferation.But, as can be seen below, the heated part of the conversation was about a different topic: can and should the OSI judge a license based on its origin? Without further ado...
Does this submission to the OSI mean that Microsoft will:
-- Chris DiBona
a) Stop using the market confusing term Shared Source If not, why should the OSI approve of your efforts? That of a company who has called those who use the licenses that OSI purports to defend a communist or a cancer? Why should we see this seeking of approval as anything but yet another attack in the guise of friendliness?
I'm unclear how some of your questions are related to our license
submissions, which is what I believe this list and the submission
process are designed to facilitate. You're questioning things such
as Microsoft's marketing terms, press quotes, where we put licenses
on our web site, and how we work with OEMs - none of which I could
find at http://opensource.org/docs/osd.
-- Bill Hilf
Be careful what you ask for. Do you really want everything RMS says about
the BSD and similar licenses to be on-topic for approval of future FSF
licenses? Should it be? Or should we do the right thing and restrict our
review to the licenses themselves?
-- Chris Travers
Hey, I can sympathize - personally, I really don't approve of the
FSF, and I'd love to see the OSI turn down the GPLv3.
-- Dag-Erling Smørgrav
Except I wouldn't, really, because then the OSI would lose every shred of credibility and quickly become irrelevant - just like it would if it failed to carefully consider the licenses submitted by Microsoft, or to approve them if they were found to adhere to the OSD.
This comes back to an old question on this list: is the OSI simply
responsible for mechanically approving licenses? Or is the OSI
responsible for, as it says on the web site, "maintaining the Open
Source Definition for the good of the community"? In my opinion,
which I acknowledge is not widely held, the good of the community does
not require approving every applicable license.
-- Ian Lance Taylor
That said, I personally would be in favor of approving the Microsoft licenses. I think it is overall a benefit to the community to acknowledge that code under these licenses is open source.
OSI's role is merely to certify the licences that meet OSD criteria, and
promote the concept of open source in general.
-- Rick Moen
The OSI board's anti-proliferation efforts appear to take them one
step beyond certification though. It would seem to be that
otherwise compliant licenses could be rejected if they simply
duplicate the terms or purpose of an existing license... I would
guess that a license
that copied the Apache license and replaced all instances of Apache
with some other abstract word would be rejected, no matter what the
compatibility matrix looked like. How about a license that had
exactly the same requirements as Apache, but restated them in a
completely different way? From there, what's the *smallest*
difference in licensing terms that would be worth adding yet
another license?
-- Brian Behlendorf
I think (as I thought two years ago) that this is a case where the
anti-proliferation rules should be set aside. We are dealing with an
organization that has the potential of being a major player in free and
open source software (and if they don't like the GPL, there are plenty
of other FLOSS-producing organizations that don't like it either).
If they can only bring themselves to release such software under their
own particular licenses, so much the worse; but not more the worse than
if they never released any FLOSS software at all
-- John Cowan
So the question becomes, should OSI discriminate? Will a farmer let
a fox into the henhouse if the fox puts on a chicken suit?
-- Groklaw
I think not. Not if he wants to have any chickens. A fox in a chicken suit is still a fox and is still planning to eat his chickens. So only a stupid farmer would reason that a fox in a chicken suit, even one made from real chicken feathers, should now be allowed to reside in his chicken coop with his tasty chickens. Farmers are supposed to consider what foxes are known to do to chickens and what a fox's motives and likely purpose might be in putting on a chicken suit and sweetly pawing on the door to the henhouse.
Over time, it will probably become obvious that MS-PL and MS-CL are
merely yet more additions to the horde of insignificant/redundant
licences that, nonetheless, do pass OSD muster. They aren't innovative
or particularly useful, though they do have the minor excellence of
brevity...
-- Rick Moen
There's really nothing new, here. However, if OSI were to surrender the integrity of its certification program, that would be something new, and particularly bad. Which is easily a sufficient reason for that not to occur. The actual decision must wait for the recommendation from the OSI license approval committee and the vote of the board of directors.
Page editor: Jonathan Corbet Security The Skype outage A recent outage at Voice over IP (VoIP) provider Skype has caused quite a stir. For nearly two days, users of the VoIP software could not make calls, which set off a storm of blog postings wondering about the cause. Skype released an official explanation that did not ring true to some, leading to further speculation. Sometime early Thursday, 16 August, Skype users could no longer authenticate and connect to the network. On Friday, right in the middle of the outage, a posting to Bugtraq purported to have information about the vulnerability that was being exploited to cause the outage. Skype has since categorically denied that any attack was responsible, but suspicions persist that the denial-of-service (DoS) vulnerability reported was actually responsible for the outage. On Monday, Skype posted the following to their Heartbeat blog:
On Thursday, 16th August 2007, the Skype peer-to-peer network became
unstable and suffered a critical disruption. The disruption was triggered
by a massive restart of our users' computers across the globe within a very short
timeframe as they re-booted after receiving a routine set of patches
through Windows Update.
Though they
never blamed Microsoft or the updates themselves, many in the media did it
for them, which led Skype to clarify
their explanation of the outage.
The high number of restarts affected Skype's network resources. This caused a flood of log-in requests, which, combined with the lack of peer-to-peer network resources, prompted a chain reaction that had a critical impact. The new message provided more details, but still remained mute on one of the central puzzles: why did updates on Tuesday cause an outage starting on Thursday? While they acknowledge a bug in their software, there is also no mention of how the situation was resolved, presumably through an automatic update of their own. Overall, the explanations are fairly thin on technical detail which allows others to conjecture to try and fill in the holes. There are many millions of Skype users – the software is available for Windows, OS X and x86 Linux – for the no-cost PC-to-PC calling as well as the other services that Skype does charge for. Hopefully the free users are not depending on the service, but there are companies which use Skype exclusively; an outage for two weekdays must have been rather painful. Certainly the landline and cellular phone companies have had their problems along the way, but those tend to be regional rather than worldwide. All software even minimally more complicated than "hello world" has bugs, and those bugs will be triggered in surprising ways. Taking the Skype "perfect storm" explanation at face value, it is nearly amazing that millions of reboots could result in a network storm so severe that it would take two days to resolve. Somehow, in the interface between the Skype's centralized authentication and their P2P routing code, things went horribly awry. It does, however, give one pause about the power of the near-monoculture in desktop operating systems. It is hard, but not completely impossible, to imagine a similar scenario for Linux boxes. To start with, it is uncommon that a software upgrade requires a reboot. Within the Linux user community, there is a wide range of kernel versions running, so even if there were a critical security fix that required "all" Linux kernels to be upgraded, it would not be very synchronized – the distributions tend to have different response times. This is a bit of a double-edged sword, of course, those varying response times could leave a hole that a worm or attacker could exploit. But, because Linux boxes are controlled by their owners rather than by their distribution provider, synchronized reboots are probably not a major cause for concern. Beyond monocultural issues, there is the question of how a P2P system can be taken down by the lack of a centralized resource, in this case credentials from an authentication server. That provides a single point of failure to what is supposed to be a robust architecture, resistant to exactly those kinds of problems. There are also those who wonder if the outage was caused by an "upgrade" mandated by the US government so that they can more easily monitor Skype calls. Skype is proprietary and closed source; there is no easy way to determine whether the problem has been fixed, or even whether the problem is being accurately described. If Skype decides, or is forced, to change their software to be more easily monitored, it will be hard to detect. It might look an awful lot like a multi-day outage that clears up somewhat mysteriously. Trusting closed source software for vital communications is not the best of plans, at least when there are alternatives. Free software would not necessarily avoid these kinds of problems, but a completely decentralized network with multiple clients sharing a protocol, but little else, would certainly be more resistant to this kind of outage. More importantly, it would also be more transparent. Over time, projects like openwengo, Linphone, Asterisk and others can hopefully provide those benefits to a larger audience
Security news Ubuntu Servers Hijacked, Used to Launch Attack (eWeek) eWeek reports on a recent security breach of five Ubuntu-hosted community servers. "It was suggested during an IRC (Internet relay chat) meeting of the Ubuntu colocation team Aug. 14 that the source of the troubles might have been a Chinese IP address trying to log onto the servers by brute force "for a long time now it seems," said a participant. On Aug. 14, the community began to bring the machines back up in a safe state so that they could recover data from them. Unfortunately, according to Ubuntu Community Manager Jono Bacon, the servers were all found to be out of date, stuffed with Web software, and missing security patches—at least in the instances where it was easy to determine what version they're running. "An attacker could have gotten a shell through almost any of these sites," [Bacon] wrote in a posting, regarding a change to location server policy that resulted from the incident."
New vulnerabilities kdebase: several vulnerabilities
kernel: several vulnerabilities
nvidia-drivers: insecure file permissions
rsync: off-by-one errors
sysstat: insecure temporary files
tor: compromised anonymity
Updated vulnerabilities apache2: information disclosure
apache: multiple vulnerabilities
apache: cross-site scripting
Asterisk: two SIP denial of service vulnerabilities
avahi: denial of service
bind: DNS cache poisoning
bochs: buffer overflow
bugzilla: multiple vulnerabilities
centericq: buffer overflows
clamav: denial of service
cups: denial of service
gpdf: integer overflow
Cyrus-SASL: DIGEST-MD5 Pre-Authentication Denial of Service
dovecot: privilege escalation
dovecot: directory traversal
emacs21: denial of service
evolution: format string error
evolution-data-server: malicious server arbitrary code execution
file: integer overflow
firebird: buffer overflow
firefox: multiple vulnerabilities
firefox: multiple vulnerabilities
firefox, thunderbird, seamonkey: multiple vulnerabilities
flac123: arbitrary code execution
freetype: integer overflows
gcc: file overwrite vulnerability
gd: buffer overflow
gd: multiple vulnerabilities
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||