Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for December 7, 2006Firefox and Linux distributors The Mozilla Foundation is a valuable contributor to the free software community; it has, among other things, provided us with a free browser which has restored the notion of standards to the World Wide Web. The relationship between the Foundation and Linux distributors has occasionally been a little bumpy, however. Mozilla's trademark policies have created stress for distributors, a few of whom have decided to leave the trademarked names behind altogether. The Foundation's security update and maintenance policies have also made life harder, sometimes having the effect of force-upgrading users to newer versions in otherwise stable distributions. To some, it seems that Mozilla's main interest is now its Windows users, with Linux support relegated to second-tier status.At the recent Firefox summit, the Foundation got together with representatives from Red Hat and Novell and faced the problem directly:
Historically, there has been a great deal of tension between
mozilla.org and the Linux distros, notably over maintenance of
branches, divergence between distros, and lack of sustained
communication between the groups. All seemed in agreement that
closer cooperation and dividing responsibilities appropriately
would benefit everyone involved. A number of changes were proposed
that have general consensus among the stakeholders.
What came out of this meeting was an agreement on a number of changes which, going forward, should improve the relationship between Mozilla and the distributors; it should also make life better for Linux-based Mozilla users. A new group of maintainers - representing Linux distributors - will be pulled together "in the Firefox 3 timeline." These maintainers will have a much bigger say on what goes into the Linux builds of Firefox and will be able to help ensure that the browser integrates better with Linux. They will also have the explicit goal of moving many of the patches currently carried by distributors into the Firefox mainline, decreasing their divergence from the mainline (and from each other). Another advantage of pushing the patches up, evidently, is that it will make compliance with the Firefox trademark rules easier, since there will be fewer patches to get rubber-stamped. These maintainers will also have a bigger role in the long-term upkeep of Firefox releases. Red Hat's Christopher Aillon notes that this group will be maintaining Firefox 1.5 past the date when the Mozilla Foundation plans to let it go. This work should help the distributors keep that version secure into the future, with the result that they need not push their users to the 2.0 release before they want to go there. The Mozilla Foundation has also recognized that most Linux users run versions of Firefox built by their distributors rather than the official Mozilla builds. In the future, distributor packages will be available directly from the Mozilla web pages. That, too, should make life easier for the user community. Overall, this new cooperation seems like a step in the right direction; having Mozilla more tightly tied to the free software community can only be a good thing. These changes are unlikely to bring Debian back into the Firefox camp, however, since they will still see the trademark policy as not being DFSG-free. Debian's policy of shipping "iceweasel" will almost certainly continue. But there is an interesting conversation going on about how iceweasel is shipped as well. The issue is this: on a Debian system, it is still possible to type:
apt-get install firefox
What the packaging system will do, however, is install iceweasel. Given that the driving force behind the switch in the first place was trademark usage, it seems unlikely that the Mozilla people will be amused by this behavior - though they have made no public statements on it as of this writing. Moving away from Firefox as a result of disagreement with the rules attached to that name is arguably a reasonable thing to do. But, once that decision is made, the right thing is almost certainly to move away from the "firefox" name altogether - before the next round of "cease and desist" letters shows up.
The Free Ryzom Campaign Ryzom is a multi-player online game operated by a company called Nevrax. It has a dedicated following, but has never reached anything close to the level of popularity seen by some of its competitors. In fact, it has not reached a sufficient level of popularity![[Ryzom]](http://www.ryzom.com/multimedia/screenshots/tryker-lakeland/tryker_lakeland_cliff.jpg/image_view_fullscreen)
to keep Nevrax alive; that company has found its way into French bankruptcy
court. The future of this game is currently in doubt.
Interestingly, Ryzom has some free software roots. Just over six years ago, LWN's Development Page carried a notice about the release of NeL, Nevrax's GPL-licensed library for the creation of online games. Richard Stallman once visited the company's office. It would appear, however, that Nevrax, once it started accepting venture capital, lost interest in free software. The GPL releases slowed; instead, Nevrax started offering closed-source versions of its code. Whether Nevrax would have succeeded had it maintained its free software approach will never be known; the proprietary plan has visibly failed to work, however. Some of the original developers have not lost interest in the code, however, and they have a number of friends. Together they have founded the Free Ryzom Campaign. The plan is to raise enough money to buy Nevrax's assets in bankruptcy court, release the code under the GPL, and take the game into the future. The inspiration is clearly the Blender project, whose code was bought through donations in a very similar way back in 2002. The Free Blender project surprised everybody by raising €100,000 in less than two months. If the Blender folks can do it, the reasoning goes, why not online game supporters? Those people, after all, are already accustomed to paying for their experience.
The first step is to sell this plan to the bankruptcy court. The Free
Ryzom folks have not yet been able to release their proposal publicly, but
the core
concepts have been posted. There will be a non-profit organization
allied with the for-profit company Mekensleep and Valentin Lacambre. With
this combination, the project hopes to convince the court that it has the
If the plan is accepted by the court, Mekensleep will end up owning the code, along with the artwork, trademarks, and so on. There is some sentiment in the Free Ryzom community for transferring the copyrights to the non-profit group, but it seems that this decision has not yet been made. What is clear is that all of the code would be immediately released under the GNU General Public License (with the "any later version" language). From there, the code would be managed under the terms of the project's social contract, which is based on the Debian social contract. Among other things, it says that players own their avatars and other objects, and should be able to transfer them from one server to another. The plans call for there to be multiple servers. The current Nevrax servers would continue to be run - on a paid membership basis - as they have been until now. But the (Linux-based) server code would be free, so anybody with an interest could set up their own world and allow access in whatever way pleases them best. According to the Free Ryzom folks (who kindly talked with your editor about the project), multiple worlds were a part of the plan from the very beginning. One of the long-term goals is to revise that vision, creating the prospect of a community-driven metaverse of cooperating game servers.
In the near future, however, a number of other problems need to be solved.
There is, for example, no Linux client for Ryzom; one assumes that, once
the source becomes available, that little problem could be taken care of.
Some players are concerned about the
security implications of opening up the source; in particular, they
would hate to see the gameplay ruined by a proliferation of robots. There
Before work can begin on any of those issues, however, a more immediate problem must be overcome: the project must convince the bankruptcy court that it is the best custodian for the code. The proposal was considered on December 5, along with proposals from other interested parties. The current word is that some sort of decision will be announced sometime after December 12. Should the project prevail in court, it must then collect enough donations to complete the purchase. To that end, the project is now asking for donation pledges; at this time, all that is needed is to promise to give some money. Should the project go ahead, donors will be expected to follow through with cash. The list of pledges is quite long; if all of those people are serious, the project will be off to a good start. The free software community has accomplished a great many things in recent years, but the creation of a high-quality online multiplayer game is not among them. This is an important area, even for those of us who lack the time or interest for gaming; the sorts of virtual worlds being created for gamers can only become more prevalent and important in coming years. They may be the only place where we'll be able to find our children. Clearly, we need some good, free virtual world infrastructure. It would be nice if we could develop it entirely ourselves, but the fact is that software cast off from corporate failures has long been an important source of code. Perhaps this particular corporate disaster could yet yield benefits for the free software community. [The images all come from the Ryzom screenshots gallery, which has many more.]
What the desktop architects are talking about The third Desktop Architects' Meeting (DAM3) is being held on December 7 and 8 at OSDL's offices in Portland. Despite some rumors to the contrary, there will still be a few people in those offices, and the meeting is going ahead as planned. LWN, unfortunately, will not be represented there. Happily, most of the attendees have posted their slides ahead of the event, so it is possible to get a sense for what some of the common themes will be.Outsiders like to criticize Linux for its proliferation of distributions, desktops, and more. Within the community, we recognize this diversity as a form of wealth. The variety of Linux distributions encourages experimentation with different approaches, with the resulting lessons being learned by the community as a whole. They also ensure that we will never be locked into a single source for our software; switching distributions is an easy thing to do. Similarly, the competition between free desktop projects has inspired them all to identify their users and give them the best experience they can. There are few people who would wish for a world with a single distribution and a single desktop. Some of those who might wish for that world, however, may well be at DAM3. Diversity is good for the community, but it does make life harder for those who would support binary applications on Linux. Having to deal with a range of desktops, packaging systems, library versions, encoding choices, etc. creates a lot of work for application vendors. Someday, maybe, the free software community will be so rich that nobody will ever wish for a proprietary application for their Linux systems. Until that time, we will either have to make life easier for those vendors or simply write off a large subset of potential desktop Linux users. Some other old complaints have been raised: lack of support for proprietary codecs and DVD playback, for example. Most of the people involved seem to understand why Linux has these limitations. But they can still wish for a world where more things just worked. Hardware support also shows up in a few sets of slides. This is an area where things are getting better quickly - most wireless network adapters should be supported before too long, for example. But video adapters are still a problem. A certain amount of slide space was reserved for complaints about sound support under Linux. At the driver level, things seem to work, but not everybody likes the ALSA API. Above that, there seems to be no consensus on which sound server should be used. Without a consistent and reliable way to make noise, many desktop applications will remain hard to support. Printing also, apparently, remains a sore point, despite the great progress that has been made in recent years. One initiative which may go forward soon is the certification of printers which are well supported under Linux. Beyond that, it appears that the Portland Project is going to try to create a unified structure for print dialogs. This mechanism would try to present a consistent interface to printing which would make it easier to export - and use - printer-specific features. Desktop-specific dialogs would still do the actual user interaction, but they would be using the Portland mechanism underneath. Perhaps the most interesting thing to be seen from the slides, however, is the expanded view of the "desktop" being taken by the group. Mobile and embedded systems - from the OLPC to the Nokia 770 and telephones - are clearly seen as a sort of desktop system. Many of the issues are the same, but the incorporation of mobile applications brings new pressures. One can, with little effort, find plenty of evidence that the desktop projects have not, so far, been overly concerned with memory use and overall bloat. Small systems are forcing people to reconsider their priorities, however, and there is likely to be an increase in the amount of development time which goes into making things smaller. A few of the participants note that better tools for memory profiling would be most helpful in this task. Overall, there appears to be nobody who is willing to predict total World Desktop Domination anytime in the near future. There is, however, a clear level of interest in the Linux desktop, especially when one considers desktops which fit in a shirt pocket. Interesting things are going to happen in this area.
Page editor: Jonathan Corbet Security Keeping current with SpamAssassin rules Anyone who pays attention to their spam knows that its character changes frequently; spammers are always adding new tricks to try and evade spam filters. There is an arms race of sorts going on; the filters get better at recognizing the latest evasion attempts and so the spammers come up with new ones and the cycle repeats. To reduce the effectiveness of this spam evolution, frequent updates of the filter rulesets are needed. For users of SpamAssassin (SA), the sa-update tool makes it very easy to pick up the latest ruleset and keep that unwanted spam out of the inbox. Before sa-update, official SA rulesets updates were only available by installing an updated version of SA. Because the release cycle was often lengthy (measured in months), the developers added the ability to easily update the rulesets over the internet. At its core, sa-update communicates with a server or servers picking up rule and score files and installs them in a directory that SA uses for its updates. SA will immediately start using the new rules, though restarting spamd will be required if SA is configured that way. sa-update is configured by default to use the official 'channel' (updates.spamassassin.org), but that can be altered to tune into other SA rules repositories. The SpamAssassin Rules Emporium (SARE) is one collection of rules and scores that sa-update can use. There are multiple channels available each of which handles a different type of spam and one can mix and match the rulesets to tune the filter for the kinds of spam being seen. There are some security implications to consider: injecting bad rules or scores could lead to worse spam filtering, for example. More worrisome, however, is the fact that the update mechanism allows for plugins to be distributed, leading to potential arbitrary code execution. SA plugins are arbitrary Perl code that will be run by the filter; because it generally runs as root or another privileged user, that can be quite dangerous. sa-update uses GPG signatures on the updates to reduce this hazard, as long as the signer is really trustworthy (and the recent GPG security problem has been patched). The official channel will not distribute plugins, thereby eliminating that problem. The rulesets available change frequently and automating the sa-update process via cron can bring the system up to date on a daily or weekly basis. Another tool, rule-get is available which uses the update mechanism and provides a command line syntax based on apt-get. This is an excellent tool for helping to reduce the ever-evolving spam problem. As long as one is careful about which GPG keys to trust, it should be secure as well. Spammers are, no doubt, taking advantage of this tool to tune their spam to avoid the new rules, but using it can reduce the false negatives from the older evasion schemes or from those who have yet to test their stock scam email with the latest rules. More information and additional channels are available from the SA wiki, a good starting point is here.
Security news A severe, remotely-exploitable GnuPG vulnerability The GnuPG developers have sent out an advisory regarding a rather unpleasant vulnerability which has surfaced: "Using malformed OpenPGP packets an attacker is able to modify and dereference a function pointer in GnuPG. This is a remotely exploitable bug and affects any use of GnuPG where an attacker can control the data processed by GnuPG. It is not necessary limited to encrypted data, also signed data may be affected." It would be prudent to be very careful about feeding messages to gpg until you have a fix installed.
New vulnerabilities gnupg: buffer overflow
kernel: bridging code buffer overflow
koffice: integer overflow
libgsf: heap buffer overflow
xine-lib: buffer overflow
Updated vulnerabilities apache: cross-site scripting
apache-mod_auth_kerb: off-by-one error
asterisk: arbitrary code execution
avahi: sender id check
bind: denial of service
bugzilla: multiple vulnerabilities
busybox: insecure password generation
bzip2: race condition and infinite loop
cpio: arbitrary code execution
Cyrus-SASL: DIGEST-MD5 Pre-Authentication Denial of Service
dovecot: index cache file handling error
elinks: arbitrary file access
ffmpeg: buffer overflows
freeradius: several vulnerabilities
freetype: integer overflows
ftpd: privilege escalation
fvwm: fvwm-menu-directory command injection
gcc: file overwrite vulnerability
gdb: buffer overflow
gdm: improper file permissions
gv: stack-based buffer overflow
gzip: multiple vulnerabilities
gzip: arbitrary command execution
imagemagick: buffer overflows
ImageMagick: buffer overflows
imlib2: arbitrary code execution
jbossas: arbitrary code execution
kdelibs: integer overflow
kernel: denial of service
kernel: denial of service
kernel: denial of service
kernel: denial of service by memory consumption
kernel: denial of service
kernel: denial of service
libgadu: memory alignment bug
libgd2: denial of service
libmms: buffer overflows
libpam-ldap: insecure password control
libpng: denial of service
libtiff: buffer overflow
libvncserver: authentication bypass
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![[Ryzom]](http://www.ryzom.com/multimedia/screenshots/fyros-desert/fyros%20special%20place03.jpg/image_view_fullscreen)
![[Ryzom]](http://www.ryzom.com/multimedia/screenshots/matis-forest/image.jpg/image_view_fullscreen)