Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for May 17, 2007On Microsoft's patent claims By now, most LWN readers will have seen this Fortune article in which a Microsoft representative makes the claim that Linux distributions violate 235 of its patents. This article has caused a fair amount of concern in the community, with some people seeing it as the beginning of some sort of Final Battle between Microsoft and free software. That might even be the case, but the true nature of the situation is far from clear. Here's a few thoughts on Microsoft's claims.To begin, these claims are not exactly new. Consider what the BBC was reporting in November, 2004:
Reuters said chief executive Steve Ballmer told Asian leaders Linux
violated at least 228 patents. The Linux community disputes these
claims. Mr Ballmer said countries using Linux which entered the
World Trade Organisation would be at risk.
So this is not the first time we have heard this sort of charge from Microsoft; perhaps the only real difference is that we have somehow managed to find another seven patents to infringe upon in the last 2-1/2 years. The possibility exists that we may not hear any more about this "violation" for another two years or so - but one shouldn't necessarily count on that. As companies go, Microsoft is relatively uninclined to pursue patent infringement suits. There was an interesting quote from the Open Source Think Tank report (covered here last week):
Sam [Ramji] defended Microsoft from the accusation that its deal with
Novell will lead to Microsoft suing other Linux distributors for
patent infringement. Sam described Microsoft's patent portfolio as
primarily defensive--at any given moment, Microsoft is the
defendant in 25-35 patent lawsuits, and that Microsoft has
offensively sued another party for patent infringement only twice
in its history.
Microsoft has, indeed, spent more time being the victim of patent trolls than a patent aggressor itself - and it has lost vast amounts of money to patent judgments in the process. This company has little to gain by heating up the patent litigation scene even more. That said, one should see the remainder of the quote above:
Sam emphasized that Microsoft has robust patent licensing programs,
and would much rather license its patents than sue.
Even if we believe that Microsoft will take a relatively enlightened approach as a result of its time at the defendant's table, we should not lose track of an important fact: companies whose core business goes away have a disturbing tendency to turn to their "intellectual property" portfolios as a way to keep the revenue flowing. Should Microsoft someday decide that Linux world domination really is inevitable, it could react in any of a number of unpleasant ways. The SCO Group's attack on Linux holds a number of lessons which can be applied to any future Microsoft attack - but those lessons only go so far. There is no doubt that interesting things will happen if you anger our community, especially if you attempt to lay claim to our work. There would be a massive outcry, publicity campaigns, boycotts, and an extended effort to invalidate as many of the patents as possible. Microsoft clearly fears the capabilities of the wider community; the Fortune article notes that Microsoft is not disclosing its specific patents "lest FOSS advocates start filing challenges to them." But invalidating even a single patent is hard; invalidating 235 would certainly tax even the capabilities of our extended community. On the other hand, Microsoft would have to name specific patents in any legal action, and, presumably, it would not base a suit on all 235 patents. There is also the unknown effect of the recent U.S. Supreme Court ruling in KSR International v. Teleflex; this ruling has raised the bar on the amount of innovation a patent must contain. Some have speculated that this ruling could lead to the end of software patents altogether. That seems like wishful thinking, but it should help those who seek to invalidate many of the software patents currently on the books. In the SCO case, a weak and incompetent company took on the strongest target it could find, and that target chose to stand its ground. There are no guarantees that things would go the same way this time around. Microsoft is strong financially and has a large, seasoned legal operation. It may well choose to attack smaller companies which cannot afford to put up an extended fight. In theory, a patent attack against Linux should evoke a strong response from the companies working with Linux, many of which hold considerable patent portfolios of their own. In practice, we will never know who would jump into that fight until they make their move. In particular, a defense which challenges the validity of software patents in general could be seen by a number of potential allies as being against their interests. We should, at least, be able to count on the intervention of the Open Invention Network, which was formed for just this purpose. If OIN's patents are as strong as some believe, the resulting fireworks should be worth watching - from a safe distance. There are a few other interesting things to keep in mind. Software patents are a U.S. problem, primarily; a successful patent attack against Linux could have the effect of driving its developers and users out of the country. Linux is now sufficiently firmly entrenched that attacking its users or developers could cause extended chaos - it might even upset more people than threatening to shut down the Blackberry network. That, in turn, could inspire more thought on the true costs and benefits of the current patent regime in the U.S. Some people believe that, by selling Novell's coupons, Microsoft has become a Linux distributor and is now subject to the terms of the GPL. Any serious attempt by Microsoft to bring down Linux would bring renewed attention from the world's anti-trust authorities. Clearly, there are quite a few unknowns here. What it all comes down to is that, sooner or later, this may well be a battle we cannot avoid fighting. Once it hits, there is no telling where things will go. About the only guarantee is that it is certain to be interesting.
The sincerest form of flattery Sun Microsystems has made a big show of its open source Solaris release and its attempts to build a working development community around that system. So a number of members of the OpenSolaris community were rather surprised when the press started running articles stating that Sun had decided to embark upon a project to make Solaris look more like Linux. This community was of the opinion that, if it was expected to endorse and participate in "Project Indiana," it might have been nice to know before Sun employees started talking to the media about it.The person behind this effort, of course, is Ian Murdock, formerly of the Linux community. His position now can be understood from this interview:
When people say they want Linux, they don't actually mean they want
Linux. What they want is the Linux userland user environment and
the Linux business model. They want choice. They want the Linux
distribution and I'm the Linux distribution guy.
Project Indiana, it seems, is Sun's attempt to win over all of those people who only think they want Linux, but who really want a version of Solaris that looks likes Linux. Many of the goals of this project, as far as they can be determined at this early stage, would seem to make sense. Better package management, for example. More device drivers. Easier installation. A more Linux-like user space with our (relatively) bleeding-edge 1990's shell. And, says Ian, a switch to timed release cycles:
The big feature from my point of view though is the 6 mo. timed
release cycle. Timed release cycles have done wonders to introduce
predictability into other open source projects (e.g., Gnome,
Ubuntu). And 6 mos. is the clear winner in terms of frequency among
Linux community/developer distros--it's just enough time to do
interesting work AND have a reasonably long hardening period so the
thing is stable.
Ubuntu comes up frequently in the discussion; it's clear that some people at Sun see Ubuntu as a model worth emulating. For those of us who have been working with free software for a while, there is a certain irony in this whole plan. A Linux-like Solaris is not a particularly new concept; for many years, that's how much of the community experienced free software. Before there was a Linux system in a reasonably usable state, the best system to have on one's desk usually came from Sun. As soon as it came in the door, however, it would be loaded up with crucial packages like the X Window System, gcc, netrek, emacs, and so on. Many years ago, we all had systems which, in some ways, looked like what Project Indiana is trying to build now. Those systems did not keep an awful lot of us from jumping to Linux, though, and their cost was only part of the reason for switching. We switched to Linux because it was free, alive, fun, and clearly going places. There was always something new and interesting happening, especially in those days when running development kernels on production systems was a necessary part of making things work. All these years later, there is still always something new and interesting, and, often, it even comes nicely packaged on a regular schedule. Not many of us are looking back to the systems we used to run. So it is no surprise that the folks at Sun are putting such a big emphasis on trying to duplicate the things that Linux does right. A similar user space, timely releases, easy upgrades, and, especially, the creation of a vibrant community around Solaris. The thinking seems to be that, if they make a system which looks like Linux but which contains their kernel (which they feel to be superior - a view which is not universally shared in the Linux community), the world will flock to their door. There have been no real (public) decisions on how this project will proceed; the process for creating an official OpenSolaris project has not yet begun. There has been some initial discussion where it has been suggested that the project start by adopting the work of either BeleniX or Nexenta. This idea drew an immediate complaint from our old friend Jörg Schilling, creator of SchilliX, but it appears that the OpenSolaris community listens to Jörg about as much as the Linux community does. Regardless, it will take some time before the real shape of Project Indiana emerges. It will take even more time before we see if this project has any real impact. Certainly it should make life easier for Solaris users. But "a better Linux than Linux" is not a particularly compelling sales message. It might just turn out that people who say they want Linux actually want Linux, not another system dressed up in similar clothes. Imitation may be the sincerest form of flattery, but it is usually a poor way to regain one's past prominence.
ATI starts to come around? A fair number of LWN readers have wondered: why hasn't LWN posted anything about the statements by ATI at the Red Hat Summit to the effect that it would be changing its relationship with the open source community? Certainly this is a relationship which could use some reworking; ATI has been one of the most stubborn vendors in its refusal to release free drivers or the programming information needed to let us create those drivers ourselves. As a result, free support for ATI's older hardware has required reverse engineering efforts - and the current chipsets have no free support at all. So, one would think, a statement from ATI that it plans to change its approach would be a welcome change.As it happens, the developers in charge of making graphics work on Linux systems are pretty much unanimous in their lack of enthusiasm. This is not the first time that ATI has made promising sounds, but, so far, the corresponding actions have not been forthcoming. Graphics hacker Dave Airlie is particularly unimpressed, noting that ATI has not yet bothered to communicate its intentions to the developers:
As for working with the community I'd expect they'd at least try
talking to the ppl who maintain the ATI open source driver if they
intend on doing something with it...
Dave is particularly annoyed because he has been sitting on the code which implements 2D support for the R500 chipset for many months while waiting for ATI to give him permission to distribute it. There is no ATI code in this driver; Dave is asking permission because he signed a non-disclosure agreement with the company. So far, that permission has not been granted. Until that changes, it's hard to believe that ATI is interested in free support for its hardware. There is one thing which has changed: ATI is now part of AMD. Historically, AMD has been much more friendly toward the free software community. It could well be that this approach is now filtering down through ATI and could result in some real changes. But we should not celebrate too much until ATI follows its words with some concrete actions.
Waiting for Emacs 22 (and looking forward to Emacs 23) The much-delayed Emacs 22 release has been covered here a couple of times recently. Since the last article, it would appear that the Emacs process has hit its lowest point, and things should be getting better from here. In the long term, though, the Emacs developers may have to take a hard look at their release management process if they want to keep the project healthy.The low point was probably sometime around when Richard Stallman got tired of people asking when a release might happen:
I have been insulted and abused many times here lately. I did not
respond to most of these insults, but I did take offense.
A number of developers responded that they had no intent to insult or abuse, but that they do have real concerns about how the process works. A couple of examples:
The current feature freeze has now lasted for more than 3 years,
during which Emacs _development_ has practically been at a
stand-still, so it is no wonder your team of _loyal_ developers is
getting frustrated and starts to question your principles, and may
start looking for other (more productive) projects to work on.
(Kim Storm).
I learned a bit of lisp, applied some basic color scaling theory,
and produced a patch which added great new functionality.... That
was Summer, 2001. Six years later, and the fruits of my early toil
still aren't available in any released version of Emacs. So, while
I continue to maintain a personally relevant programming mode, and
contribute bug fixes where they impact that mode, I have not taken
on any other "feature improvements" to Emacs. To me, the value
equation just doesn't compute.
(JD Smith). Clearly, the extended Emacs development cycle is proving frustrating for developers. The situation with the Linux kernel was once similar; changes merged at the beginning of a development cycle could take years to make it to a stable release. In that case, distributors responded by backporting changes into older releases, but that doesn't happen with Emacs. The good news is that the biggest blocker - some questions about whether the Python mode code could be distributed by the FSF - appears to have resolved itself in the best possible way: the code has been cleared. Inevitably, there's another bug or two in need of squashing before the release can happen, but the remaining wait should be relatively short. Hopefully. Some of the Emacs developers are already looking forward to the Emacs 23 development cycle. One of the first things that may go in is multi-tty support, which allows a single emacs instance to drive multiple terminals or X connections. This code apparently still does not work on all architectures, though, meaning it needs some work before it is truly ready. The other big change is a complete rework of character set handling; only Emacs would come with a news item reading "The Emacs character set is now a superset of Unicode. (It has about four times the code space, which should be plenty)." There's a lot of other work waiting to be merged, but getting the unicode-2 branch and multi-tty working together looks like it should be enough to keep the developers busy for a little while. Happily, they are starting to think about this sort of challenge rather than wondering if their previous work will ever be released.
The Open Source Business Conference The Open Source Business Conference is happening on May 22 and 23. For the first time, LWN will be present at this event. Look next week for coverage on what's happening on the business side of Linux.Beyond that, your editor somehow got talked into sitting on a panel dedicated to the question "is the Novell-Microsoft deal good for open source?". Given recent events, one might expect interest in this topic to be high. It should be a memorable experience; your editor can only hope that there is a pub within quick walking distance of the venue for the post-event recovery process.
Page editor: Jonathan Corbet Security Critical Vulnerabilities in Samba The three vulnerabilities in Samba reported this week should have network administrators scrambling to patch vulnerable servers. Most distributors have already done their scrambling to pick up and apply the fixes so they could release updated samba packages. Each of the vulnerabilities could lead to root privileges; two of them are remotely exploitable - just the kinds of security holes that give administrators nightmares. No exploits have yet been reported, but it is probably only a matter of time; unless they run a completely trusted environment, Samba users need to patch these holes. The Samba project provides a free implementation of the SMB/CIFS protocols that allow file and print sharing on Windows networks. With Samba, Linux (and other free operating systems) can participate as either a client or server in a mixed OS environment. As Microsoft is not known for its ability (or, perhaps more accurately, willingness) to play well with others, the Samba team has reverse engineered the protocols and the way they are used by Windows so that Samba can bridge that gap. Somewhat surprisingly, the project was not singled out in the latest patent saber rattling by Microsoft; it is probably just an oversight as Samba is precisely the kind of package that Microsoft would want to spread patent FUD about. The vulnerabilities themselves are fairly straightforward bugs, but it is instructive to look at them; understanding security holes helps avoid them in future code. The first is the shortest lived of the three, only affecting versions 3.0.23d through 3.0.25pre2, whereas the other two affected all versions from 3.0.0. An attempt to simplify the handling of transitions to and from root privileges in the smbd server process is the cause. When looking up System Identifiers (SIDs) in a local list of users and groups, it may transition to rather than from the root user allowing a local attacker to perform some operations as root. The second reported vulnerability appears to be the most serious as it is remotely exploitable without requiring authentication with the Samba server. By sending specifically crafted packets to the server, an attacker could cause the heap to be overwritten, leading to execution of code provided by the attacker. The underlying cause, as shown by this patch, is not checking for NULL as the return value from a memory allocation routine. The final report concerns unsanitized user input that is passed to /bin/sh to be executed. By using shell metacharacters in the data sent, an attacker could execute code on the server. If the 'username map script' option has been enabled in smb.conf (it is off by default), the remote attacker need not be authenticated with the server to execute the code. In the standard install, a remote user would be required to authenticate to gain access to the file and print sharing management features before being able to exploit this vulnerability. With the exception of the SID lookup botch, these kinds of bugs are not new and not specific to Samba. Some variant of the user input filtering problem is the root cause of the majority of web-based security problems and forgetting to check for NULL in allocations is as old as the C language itself. It is probably a bit embarrassing to the team, but it is not surprising that these kinds of problems creep in. Programming securely is difficult and there are a lot of ways to go wrong. Based on the timelines, the Samba team responded promptly in getting fixes out and made sure the word got out. This is the right response in the face of these inevitable bugs.
New vulnerabilities bind: denial of service
samba: several vulnerabilities
squirrelmail: missing input sanitizing
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
clamav: several vulnerabilities
cups: denial of service
Cyrus-SASL: DIGEST-MD5 Pre-Authentication Denial of Service
dovecot: directory traversal
elinks: code execution
evolution: format string error
pop mail man-in-the-middle attacks
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
gimp: arbitrary code execution
gimp: symlink issue
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
kernel: denial of service
kernel: multiple vulnerabilities
kernel: denial of service
kernel: multiple vulnerabilities
kernel: denial of service
kernel: denial of service
kernel: denial of service
kernel: denial of service by memory consumption
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||