Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for June 7, 2007Looking forward to Fedora 8 Given the amount of work which went into the recent Fedora 7 release, it would not be surprising if the Fedora developers were to go off and focus on beer consumption for a little while. As it happens, the beer is (mostly) staying in the refrigerator and the Fedora community is getting a quick start on the Fedora 8 release; the beginning of a feature list is in the works. The draft schedule has been posted, and it is ambitious: Fedora 8 is due on October 31 (Halloween), after a mere five months of development.This schedule has raised some eyebrows within the community. Five months seems quite short for the development of a new version of this distribution. The final development freeze is on October 17, which disappoints KDE fans: the KDE4 schedule calls for an October 23 release. If one looks at the feature freeze date (August 20), then Fedora 8 appears poorly aligned with the GNOME 2.20 schedule as well. Why, it is asked, should the Fedora project rush out a distribution under a tight schedule which causes it to miss the major developments that users are looking for? The answer lies in the Fedora leadership's desire to get the distribution back onto a regular six-month schedule. A predictable release pattern is better for everybody involved. Users know when it will happen, and major development projects can, if they care, plan their own schedules around the distribution releases. Fedora's releases have been a bit less predictable than usual recently, an understandable result of the changes the project has undergone. But Fedora 8 looks like a good opportunity to bring things back in line. That reasoning still leaves open the question of why this cycle needs to be only five months long. The Fedora folks are juggling a couple of other concerns here. One of them is that final distribution releases are best placed far from the end of Red Hat's fiscal quarters; it seems that it's a lot easier to get peoples' attention when they're not trying to close out a quarter. The Fedora leadership has also noticed that, just occasionally, Fedora releases have been known to slip back a bit from their planned date. Putting that date in October allows for a certain amount of slippage without pushing the release back into the middle of the holiday season. A Fedora release as a Christmas/Hanukkah/Kwanza/Yule present is a pleasant idea, but it's less pleasant for Fedora developers who may have other plans during that time. The end result of all this is that Fedora is likely to cling fairly tightly to an April and October release schedule. We are seeing a similar pattern with some other distributions, and with other large projects. Over time, perhaps, some sort of loose, global coordination of release schedules across much of the community is emerging. That would be an interesting example of spontaneous organization where few expected it to happen. Meanwhile, there is still some significant grumbling within the ranks of the Fedora developers who came from the Extras side of the distribution. Putting an updated package into the old Extras repository was a simple process; now the "short form" of the packaging guidelines shows a 15-step process to upload a single package. A new requirement to route packages through the updates-testing area was the last straw for some developers who were already unhappy with what they see as a heavy bureaucracy which has been imposed upon them. There is talk of having lost control of what used to be a community-oriented Fedora Extras distribution. This discussion should be looked at with the understanding that the merger of Fedora Core and Fedora Extras was a major change in how Fedora is made. Naturally there will be culture clashes, growing pains, and conflicts as two very different sets of processes are merged into a single, new process. The path toward a solution was articulated clearly by longtime contributor Thorsten Leemhuis:
So lets deal with it now -- for example by making "contributing to
Fedora easy again, get the community involved better into the
decisions process and make packagers happy again" one of the most
important "Features" for Fedora 8. Otherwise the merge might fail
in the end.
Disagreements within large projects are not uncommon, even without the added stress of major change. The open nature of projects like Fedora causes these disagreements to unfold in very public ways. The good news is that if the project's participants are serious about pursuing a common goal - creating the best free distribution they can, for example - they usually find a way to address the issues and move on. With any luck the remaining difficulties from the merger will be a distant memory by the time we're thinking that our Fedora 7 systems are getting old and are in need of an upgrade.
Whose project is it anyway? A project's name is its identity which embodies all of the good (or bad) will that the software and its developers have built up over time. In order to protect it, a project will sometimes register a trademark for the name allowing them to control who uses it. If someone outside of the project tries to grab that control by registering the trademark, especially without consulting the development team, sparks will fly. That is just what we are seeing in a dispute between handhelds.org and two of the projects associated with it. As one might guess from the name, handhelds.org is essentially a portal for open source, typically Linux-based, software for small embedded devices, mostly PDAs. It provides CVS repositories, bug tracking, mailing lists and other developer services to a handful of projects related to handheld devices. The GPE Palmtop Environment (GPE) and the Open Palmtop Integrated Environment (Opie) provided a user interface including some Personal Information Management (PIM) applications for PDAs. Both projects were developed using the facilities at handhelds.org, but it is apparent that there is a disconnect between the projects and the portal: is handhelds.org just a hosting site like SourceForge or is it something more? That question is at the heart of the disputes. In August of 2006, several GPE Palmtop Environment (GPE) developers proposed moving the project from handhelds.org to a relatively new site called Linux-To-Go (LTG). The stated reasons for the move were somewhat vague, but it clearly was an attempt by those developers to gain more control over the hosting of the project and which development tools were used. It was perceived to be a power grab by some and was not met with wholehearted acceptance, but the main detractors were people associated or affiliated with handhelds.org rather than core GPE developers. Another round of mailing list flames came about in October when the move to LTG actually started to happen. As with any acrimonious split, there were accusations of various sorts being thrown around, the GPE developers were accused of deleting the CVS repository on handhelds.org while handhelds.org was alleged to have deleted user accounts, links to the new site and mailing list messages. The transition seems to have gone well for LTG as most or all of the GPE developers moved over to the new site. All of that bickering is well in the past now, the GPE project has moved on, and handhelds.org continues to host various projects, but a dispute over an Internet Relay Chat (IRC) channel has recently rekindled the flames. The administrators at freenode surely had no idea what they were stepping into when they acted on a renaming request from handhelds.org and pointed the #gpe channel at #handhelds-gpe. The #gpe channel had been in use by the project at LTG, and a request to control the channel had been made by LTG in November but had not yet been acted upon. When freenode discovered the problem they restored the channel to the LTG folks and promptly received an email from handhelds.org claiming GPE as their trademark. At that point, freenode took the channel away from both awaiting a resolution of the dispute. It turns out that in March, George France, CEO of Handhelds.org Inc., which is the non-profit company that runs the website, applied to register trademarks for several of the projects that are hosted there. GPE and Opie were two of those projects. Then in mid-May under cover of an innocuous CVS comment, France changed the handhelds.org legal page to include a statement claiming that GPE, Opie and another 11 projects as "Trademarks of Handhelds.org, Inc." France claims that GPE and Opie were always trademarks of handhelds.org and the registration is just to clean up the legalities of the matter:
Although I am not a lawyer, in the united states, a trademark comes from using
a mark in trade, which is known as an unregistered mark. You can not
register a trademark in the US unless it has been an unregistered mark first.
Registration is just bow, that gives extra rights like presumptive [ownership].
Opie has been a trademark of handhelds.org, inc for a long long time. Now it
is more visible, but nothing new is going on.
The GPE folks claim that the name GPE pre-dates hosting on handhelds.org and that the active project should be the one to hold the trademark, as all handhelds.org ever did was provide hosting services. France never consulted with either project regarding registering the trademarks, presumably because he believed them to be already the property of handhelds.org. It seems fairly presumptuous to claim a project's name, even for the most altruistic of reasons, without consulting the people whose code embodies that project. Whether the handhelds.org folks wish to acknowledge it or not, the active GPE project is now hosted at LTG. The GPE mailing list archives show no activity of consequence at handhelds.org since April whereas the LTG list is fairly active. Under those circumstances it seems disingenuous to suggest, as some handhelds.org folks have, that the LTG project is a fork and should therefore change its name. GPE has moved rather than forked. Opie seems to have gotten caught in the GPE crossfire to some extent. The project itself was not very active when one of the earlier developers tried to start an OpieII project that would update the code to Qt4. His choice of hosting it at LTG was at least partially to blame for a request from handhelds.org that he not use the name OpieII as it infringes upon the Opie trademark. This led to yet another flame-filled thread about handhelds.org usurping a project's name, but it also led to a possible solution to the whole mess. One of the original Opie founders stepped in and has come up with a possible resolution where he will be licensed to use the Opie name and will host an Opie development site separate from handhelds.org (though still affiliated as opie.handhelds.org). In addition, a community council for handhelds.org would be formed and a code of conduct would be created to try and avoid these kind of situations in the future. One might hope this model could lead to better relations between GPE and handhelds.org, but egos on both sides would make that an unlikely scenario. If a loose collection of developers comes together and starts contributing code to a project, one would think that they would be entitled to own the trademark on the name they chose. But unless the project puts together some kind of governing structure and applies for a trademark at or near day one, there can always be questions about the name. Does it belong to the founders, the current developers or the site that hosts their CVS repository? How do you define who is a "member" so that the governing structure adequately represents the interests of the "community"? These are difficult questions and are probably about the last thing a group of hackers wants to deal with at the initial stages of a project. In many cases, it is too early to tell if the project will even get going enough that it makes sense to spend any time on governance issues. Trademarks are a bit of a double-edged sword, they can protect a project from someone misrepresenting the code, a spyware infested browser called Firefox for instance, but there needs to be some kind of entity that administers and enforces the mark. It would be difficult for someone completely unrelated to a project to register the trademark and hope to have it stick, as William Della Croce found out with the Linux trademark in 1996, but it costs real money to wrest the trademark back, and a free software project is unlikely to have that easily at hand. This is an issue that project leaders need to at least think about as their projects mature.
Last call for GPLv3 The Free Software Foundation has announced the release of the "last call" draft of version 3 of the GNU General Public License. In the absence of a significant reason to make changes, the FSF will be releasing something that looks very much like this draft on June 29. So this would be a good time for anybody who is concerned about this license to take a final look at the license text with an eye toward finding any last-minute problems.There are a few significant changes that went in this time around, and one which did not. The current draft contains this language:
You may not convey a covered work if you are a party to an
arrangement with a third party that is in the business of
distributing software, under which you make payment to the third
party based on the extent of your activity of conveying the work,
and under which the third party grants, to any of the parties who
would receive the covered work from you, a discriminatory patent
license (a) in connection with copies of the covered work conveyed
by you (or copies made from those copies), or (b) primarily for and
in connection with specific products or compilations that contain
the covered work, unless you entered into that arrangement, or that
patent license was granted, prior to 28 March 2007.
The final part is the "grandfather clause" which exempts the Microsoft/Novell deal from this restriction. In the previous draft, the FSF had mentioned the possibility of removing that clause, causing the full power of that language to apply against Novell. That, in turn, would have made it hard (or impossible) for Novell to distribute software licensed under GPLv3. According to the FSF, it now seems that it is better to let Novell distribute this software than to prohibit it:
Microsoft is scrambling to dispose of as many Novell SLES coupons
as possible prior to the adoption of GPLv3. Unfortunately for
Microsoft, those coupons bear no expiration date, and paragraph 6
has no cut-off date. Through its ongoing distribution of coupons,
Microsoft will have procured the distribution of GPLv3-covered
programs as soon as they are included in Novell SLES distributions,
thereby extending patent defenses to all downstream recipients of
that software by operation of paragraph 6.
If this reasoning holds up, any Microsoft patent which can be said to be infringed by GPLv3-licensed software distributed by Novell will, in essence, be licensed to the free software community. It seems too good to be true, but the people who are arguing this point should know what they are talking about. The definition of a "user product" - the sort of product to which the anti-DRM provisions apply - has changed somewhat. The previous draft used a reference to a U.S. law, which was not entirely well received in other parts of the world. The new draft says, instead:
A "User Product" is either (1) a "consumer product," which means
any tangible personal property which is normally used for personal,
family, or household purposes, or (2) anything designed or sold for
incorporation into a dwelling. In determining whether a product is
a consumer product, doubtful cases shall be resolved in favor of
coverage. For a particular product received by a particular user,
"normally used" refers to a typical or common use of that class of
product, regardless of the status of the particular user or of the
way in which the particular user actually uses, or expects or is
expected to use, the product. A product is a consumer product
regardless of whether the product has substantial commercial,
industrial or non-consumer uses, unless such uses represent the
only significant mode of use of the product.
The clear intent is to define most products as "user products," exempting only a very few products from the requirement that "installation instructions" be provided with the source. This requirement has always been one of the most controversial parts of GPLv3, but the FSF has stuck with it from the beginning. The permissions for distributing copies have been broadened a little with this language:
You may convey covered works to others for the sole purpose of
having them make modifications exclusively for you, or provide you
with facilities for running those works, provided that you comply
with the terms of this License in conveying all material for which
you do not hold copyright. Those thus making or running the covered
works for you must do so exclusively on your behalf, under your
direction and control, on terms that prohibit them from making any
copies of your copyrighted material outside their relationship with
you.
In other words, having an outside contractor work on a modified, GPLv3-licensed program does not force the distribution of the modifications to that program. Finally, this draft of the GPLv3 is considered to be fully compatible with version 2 of the Apache License. This compatibility was achieved by changing the interpretation of the Apache License slightly (in a way which matches the Apache Software Foundation's interpretation) and by adding a couple of permissible extra terms to the GPL. It is now possible to require indemnification of upstream contributors and to require modified works to be distributed under a different name. Since the Apache License contains terms like that, allowing them under GPLv3 was essential if the two were to be made compatible with each other. The screaming which accompanied earlier drafts of GPLv3 is notably absent this time around. A number of the issues which upset people have been resolved at this point. And most observers understand that other controversial terms - such as the anti-DRM provisions - are not going to change regardless of how much criticism is directed at them. For better or for worse, the GPLv3 process is nearly complete; soon it will be a matter of seeing which projects make the change to the new license. To that end, Richard Stallman has posted an essay encouraging movement to GPLv3. Starting on June 29, projects will have the option of following that advice.
Page editor: Jonathan Corbet Security Firefox security status A major security flaw in various third-party extensions has given Firefox a bit of a black eye even though the browser is not vulnerable. A number of other issues in the browser itself caused a security release which kept Firefox in the news. Unfortunately, after the release, even more vulnerabilities were reported. One would have to guess that it has not been the best week or so for the Firefox security team. A large number of extensions - including toolbars for Google, Yahoo, Facebook and others - are susceptible to a man-in-the-middle attack that allows arbitrary code execution within the browser. The vulnerability exploits the update mechanism built into the extensions by providing malicious code as an update. An attacker that can control the DNS answers received by a victim can redirect the update queries from the extensions to a server under the attacker's control. The code provided gets installed, silently in many cases; it will then run as part of the browser with all of the capabilities of an extension. Situations where one may not be able to trust the DNS answers received are far more common than people realize. Using a public or unencrypted wireless network is probably the most common vulnerable situation, but home routers that have been subverted either through a vulnerability or because the owner never changed the default password can also leave an opening for an attack. Because the extensions typically check for updates frequently, there are lots of opportunities to provide them with bad code. There are any number of nasty things that a browser extension can do: keystroke logging, email reading, spamming, bank transfers, subscribing to LWN.net, etc. This is truly a situation that one wants to avoid. Vendors of these extensions have in many cases (with Google being specifically called out in the vulnerability announcement) bypassed the default Firefox prompt that would at least alert users that new code was being installed. Users running those extensions have no defense and need to delete them from the browser while awaiting a fix from the vendor. The open source extensions that are available at https://addons.mozilla.org are not vulnerable because of the use of SSL to prevent an attacker's host masquerading as the update server. The SSL certificate presented by the attacker's server will not pass muster with the browser so the malicious update will not be installed. This is the fix that the vulnerable extensions will have to implement. It is not particularly technically difficult, more of a logistics headache to roll out new code to millions of users. It may also require some infrastructure improvements to be able to support encrypted connections for that many users. Millions of users at risk for all manner of browser mayhem may make the fixes in the most recent security update pale by comparison but there are some serious issues there as well. The most important fix, rated as critical by Mozilla, fixes potentially exploitable crashes in the layout and Javascript engines. There is also a flaw that allows cross-site scripting using the addEventListener Javascript call which Mozilla rates as having a high impact. A few days after the release, Michal Zalewski was up to his usual tricks by reporting two vulnerabilities in Firefox, one that he rates as a major vulnerability, the other as medium. In both cases, various Javascript tricks can be used to make the browser behave badly which is yet another reason to look into the NoScript extension. Thor Larholm also had some bad news for the Firefox team shortly after the release when he reported that a patch that went into the 2.0.0.4 release only partially fixed the problem for Windows platforms while doing nothing to prevent the problem for Linux and other UNIX versions. The directory traversal vulnerability allows any local files accessible to the browser user with the name known by the attacker to be read via the resource:// URL handler. The information in the file could then be transmitted to any site visited. We can probably expect an update from the Firefox team for this particular problem relatively soon.
Security news Google: Web Server Software and Malware Google has published the results of some research on web servers and malware. "It is very interesting to see that in China and South Korea, a malicious server is much more likely to be running IIS than Apache. We suspect that the causes for IIS featuring more prominently in these countries could be due to a combination of factors: first, automatic updates have not been enabled due to software piracy, and second, some security patches are not available for pirated copies of Microsoft operating systems. For instance the patch for a commonly seen ADODB.Stream exploit is not available to pirated copies of Windows operating systems." So the problem may not be that the software is inherently less secure, but that its proprietary licensing cuts off many deployments from security updates.
New vulnerabilities clamav: denial of service
file: integer overflow
firefox: multiple vulnerabilities
jasper: denial of service
lha: temporary file vulnerability
libexif: integer overflow
php: multiple vulnerabilities
php-pear: directory traversal
Sun JDK/JRE: multiple vulnerabilities
wpa_supplicant: buffer overflow
Updated vulnerabilities apache: cross-site scripting
Asterisk: two SIP denial of service vulnerabilities
bind: denial of service
bugzilla: multiple 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
file: arbitrary code execution
firefox: FTP PASV port-scanning
freetype: arbitrary code execution
freetype: integer overflows
gcc: file overwrite vulnerability
gd: buffer overflow
gdb: buffer overflow
gforge: arbitrary code execution
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
kernel: denial of service
kernel: multiple vulnerabilities
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||