LWN.net Weekly Edition for July 22, 2010

The end of the road for the Nexus One

On July 16, Google quietly announced that it has received its last shipment of Nexus One phones; once those have been sold, Google will no longer sell the device. Commenters in the media have immediately seized on this announcement as a sign of the failure of Google's attempt to get into the handset business. That it might be, but the real implications of this event may be different from the "carriers rule" message found in the mainstream press.

The Nexus One, of course, is an Android device. It is a quite nice handset, really, but the world is increasingly gifted with a wide choice of nice Android handsets. What sets the Nexus One apart is its relative openness; it need not be jailbroken, the bulk of its necessary software is free, and there is a variety of alternative Android builds to run on it. No other current-generation Android handset is so open, with the near-exception of the Motorola Droid - but Motorola has made it clear that the Droid's successors will not be so easy to work with. When the Nexus One is gone, if and until something else replaces it, the Android world will be more closed than it was before.

It is worth noting that the Nexus One is not going away entirely; it will be available alongside the ADP2 handset for developers set up as publishers in the Android market. But it will no longer be available as a mainstream consumer item.

The Nexus One has been widely portrayed as a commercial failure - and perhaps it is. It is an expensive device - on the face of it, rather more so than a shiny new iPhone 4, and it doesn't even come with a free case. The headline version only works well with the smallest carrier in the US, though an AT&T-capable version was eventually released as well. No US carriers sell it to their customers directly (your editor did just stumble across one for a mere €500 in a European Vodafone store). Promotion of the Nexus One was minimal and, seemingly, limited to Google's advertising network. Prospective customers have also figured out that, despite its towering strengths elsewhere, Google really just doesn't quite get the concept of customer support.

So the odds were rather stacked against this device from the beginning. One could hope that the prospect of an open device would be enough to motivate people to overcome the obstacles listed above and get a device like a Nexus One anyway. But the truth of the matter is that, at this point, openness at that level is not much use to most handset users. Your editor will confess that he still feels a certain childlike joy at the prospect of reflashing an expensive device that he depends on, possibly bricking it, then painfully restoring all of the settings and discovering all of the new bugs which have been added. It's the sort of adrenaline experience that others, perhaps, seek through horror movies, bungee jumping, investing in equities, or PHP programming. There is no accounting for taste, it seems. Not that many customers have a taste for the Nexus One experience, especially when even relatively locked-down Android handsets seem more open than many of the alternatives.

[PULL QUOTE: The pessimistic among us can be forgiven for concluding that the battle for open handsets is being lost. END QUOTE] The pessimistic among us can be forgiven for concluding that the battle for open handsets is being lost. The carriers determine which devices will be successful in the market, and they have absolutely no interest in openness. Customers are irresistibly drawn to heavily advertised, shiny devices with low up-front costs; they just do not see any reason to insist on more open devices or, even, freedom from carrier lock-in. Attempts to create a market in open handsets - Nexus One, OpenMoko - seem to go down in flames. By this reasoning, we may well all be using Linux-based handsets in the future, but the freedom that attracted many of us to Linux will have been lost.

By now, some readers are certainly protesting that this discussion ignores another mostly-open device: Nokia's N900. It's not clear that the N900 has been a commercial success either; your editor has yet to see one outside of a Linux-oriented conference. Still, the N900 might just point toward an interesting, less pessimistic future.

The MeeGo system remains a bit of a dark horse; it's arriving late to a well-established party. But MeeGo has some interesting attributes, including a real attempt to create an open, community-oriented culture and the backing of a pair of large companies with significant stakes in the outcome. Nokia and Intel are both watching the smartphone market happen without them; Nokia, in particular, very much needs to find a way back into the game. MeeGo appears to be part of the plan for that reentry, so considerable resources are being put into its development. As a result, MeeGo is quickly developing into something interesting.

If MeeGo handsets make their debut as "Android without all those annoying free Google services," they may find an unenthusiastic reception. But, just maybe, MeeGo can come in offering a better, more interesting experience which includes a higher level of openness. The N900 has already attracted a significant development community, one which is more tightly tied into the free software community as a whole. MeeGo, in a sufficiently open setting, might be able to engage the wider community in a way that Android has not, yet, succeeded in doing. If MeeGo takes off, some surprising things might just happen.

From the July, 2010 perspective, that all looks like a tall order. It depends on the availability of open handsets (which are currently nowhere in sight), solid software releases, a continued opening of the MeeGo project to the community, and a sufficient level of commercial success to keep the whole thing going. The odds seem daunting, but it's worth remembering that, not all that long ago, Android, too, was dismissed as a too-little-too-late offering in a crowded and maturing marketplace. There is also a wild card out there in the form of Palm's WebOS, now under HP's management. It may yet come to pass that, in the near future, the handset market will be dominated by competing, Linux-based devices where the strength of the development community - driven by the openness of the platform - is a key factor.

Comments (33 posted)

Wesnoth struggles with App Store's GPL incompatibilities

In light of the recent GPL compliance complaint made by the Free Software Foundation against Apple's App Store, which sells and distributes software for Apple gadgets, it was probably inevitable that other problem applications would surface. While there are various opinions on whether the App Store can legally distribute GPL-covered binaries—along with diverging opinions on what benefits, if any, the App Store provides to free software projects—it is clear that some people object to their GPL-licensed code appearing in the App Store. So it shouldn't come as a huge surprise that the port of the The Battle for Wesnoth for the iPhone/iPad, which was released last November, has run into some resistance.

As is usual for the wesnoth-dev mailing list, the discussion was largely polite and respectful, but there was clear disagreement. Rusty Russell raised the issue after a friend showed him Wesnoth running on an iPad: "That's great, except that it came via the Apple App Store. I didn't think that was allowed under the GPL?". He pointed to the FSF's blog post about GNU Go, and noted that he was "uncomfortable with Apple's restrictions on the devices after they sell them".

Wesnoth lead developer David White responded that, unlike GNU Go, Wesnoth had been ported to Apple's devices with the explicit endorsement of the development community. He and the other developers, including Kyle Poole who did the port, believed that the port was "acting within the GPL" because the source was available and:

White went on to describe the benefits that he saw from putting the application into the App Store: revenue for the project, which is being used to fund art development, and raising the profile of FLOSS gaming. He noted that it helped users become more aware of FLOSS games, but also made other free software game projects aware of the App Store as a distribution platform. Russell didn't find those to be particularly compelling arguments in favor of distributing Wesnoth in the App Store, in fact he found the opposite to be true.

Because the App Store EULA imposes restrictions on what users can do with the binaries they download, the FSF and others believe that it runs afoul of the "further restrictions" clause in section 6 of the GPL. As Russell points out, the "walled garden" that Apple is creating violates his understanding of users' rights under the GPL:

In addition, Russell is skeptical that users are really being exposed to free software gaming, instead they are just finding "a great game for $5". He also believes it's "self-defeating" to strengthen the Apple platform by putting more free software on it. But others clearly disagree. Patrick Parker noted that it was not a secret that an iPhone port was taking place, as it had been discussed on the forums and on IRC, and that a complaint at this late date was "selfish". Furthermore, he was unhappy seeing Wesnoth used as a weapon:

Russell agreed with some of that, saying that he worked on Wesnoth because it aligned with his selfish goals: "I want to encourage Freeness, and helping Wesnoth seemed like a good way to do that. Or, if you prefer, 'a tool in the "Freeness" war'." But he also acknowledged that others had different goals, which is where the license comes into play: "that's why we have a license, and a common understanding of what it means".

The FSF's complaint, which raised the license issue for the first time, came well after the Wesnoth port was completed after some eight months of work by Poole. That puts the project, and White in particular, in an uncomfortable position. His "main concern" when Poole approached him about porting the code was to ensure that the full source code would be available. The source is available, but White is, to some extent, stuck between a rock and a hard place:

Poole describes the port as having an impact that is very much in keeping with the ideas behind the GPL, even if Apple's EULA tries to hinder it:

But the power grab enabled by Apple's EULA is sweeping, which is what concerns Russell: "AFAICT, the device is designed not to allow the freedoms the GPL tried to guarantee." By not allowing Wesnoth binaries to be redistributed, Apple has gone further than others, he said:

His question remains unanswered, at least directly, but certainly some see the arguments made by Russell and the FSF as too rigidly interpreting the GPL. For example, Richard Kettering resolutely defends what he perceives to be the interests of the artists and musicians in the project:

The irony of that last sentence seems to have escaped Kettering, but Russell is quick to point it out: "Generalize the words 'just because you dislike the platform' to 'for any reason' and you've summed up the problem with these devices very well :("

White has suggested that a list of Wesnoth contributors be created from the Subversion logs, and that each be contacted to be made aware of the situation. Any that are willing can make a licensing exception to allow their contribution to be used in an application distributed through the App Store. Those that aren't willing, and Russell and others may well be in that camp, would have their contributions removed from the App Store version.

Exactly what form that exception would take is up in the air. Paul Ebermann is concerned that wording it will be difficult, but White disagrees as he thinks a specific App Store exception can be made. Currently, the plan is to convene an IRC meeting of all concerned project members to discuss the problem. Decisions on license exception wording, as well as a plan to remove any content from contributors unwilling to agree, will presumably be worked on as part of that meeting.

Apple does provide the means for applications to present their own custom EULA, so Poole looked into the possibility of using the GPL as Wesnoth's EULA. But, Apple has closed off that potential remedy as well: "Apple states that any custom EULA must meet their 'minimum terms' which can't be more permissive than their default." But, as Gabriel Morin pointed out, there are even worse terms in the Apple's iPhone Developer Program License, which Poole was required to sign, but he "probably didn't mention it since the agreement prohibits making public statements about it". Morin doesn't see how it is at all possible to reconcile the GPL and that agreement.

This is clearly a clash between a license intended to ensure user freedoms and a company hell-bent on ensuring that it is in complete control of what can run on the devices it sells. There may be ways to remove code or content from the Wesnoth codebase, such that all that remains has some kind of license exception to allow it to run on iPhones and iPads, but the question will still remain: does working around Apple's draconian requirements really help the cause of free software? Opinions clearly vary, but it is something our communities will continue to struggle with.

One clear lesson from all of this was noted by Parker: "However, if I ever start my own open source project, I will probably require copyright removal or assignment as a precondition to inclusion (much like the FSF does with its own programs)". Had a copyright assignment to a Wesnoth non-profit been required for all contributions, all of the App Store licensing problems could have been avoided, as the copyright owner could have issued a separate license. Whether as vibrant a community would have arisen around this hypothetical "Wesnoth with copyright assignment" project is an open question.

Apple is unlikely to change its terms regardless of what Wesnoth decides. Its walled garden is working very well for it and few, if any, of its customers are clamoring for a change. While it is very cool to see a free software game like Wesnoth running on these über-trendy gadgets, it is a bit hard to see how it brings more folks into the free software world. On the other hand, it's hard to see how denying the iPhone/iPad universe access to Wesnoth is going to make a difference either. It's really up to consumers to recognize—and clamor for—devices that respect their freedoms. So far, that just hasn't happened.

Comments (58 posted)

Ubuntu's font beta sparks discussions about open font development

Canonical recently launched a "beta" testing program for its still-in-development Ubuntu font. The font is provided through an Apt repository accessible only to Ubuntu Members — individuals who actively contribute to the project, apply, sign a code of conduct, and are approved by community membership boards. The font is intended for screen usage as the default interface font in the next Ubuntu release, covering the extended Latin-A, Latin-B, Greek Polytonic, and Cyrillic character sets.

The new font is part of Canonical's branding and visual identity refresh first introduced with Ubuntu 10.04. Canonical contracted development of the font to type foundry Dalton-Maag, who is scheduled to deliver several weights of the font (including bold, italic, and monospace) in time for the October release of Ubuntu 10.10. Currently, only the regular weight is available for testing. The font name is "UbuntuBeta" inside the TrueType binary, though it may be renamed before final release.

Non-members can test the font via a web application that uses the @font-face construct in CSS 3, rendering user-provided sample text at any size from 6 to 36 points. An account on Ubuntu's Launchpad.net service is required to use the web application, though, because the tool ties into Launchpad's bug tracking system. Canonical says that the visual design of the font is complete, but is soliciting feedback from users about kerning, hinting, and other potential rendering problems. The web application allows users to select problematic glyphs in the rendered text and submit bug reports against the project.

Criticism of "closed" beta

The company's decision to restrict the current beta only to Ubuntu Members has drawn its share of ire, however. Maia Kozheva posted a blog entry styled as a letter to Canonical criticizing the restricted-access beta as "contrary to the entire spirit of free software." Several commenters at Kozheva's blog and on general news sites covering the launch agreed. Kozheva also expressed skepticism about the "open" license Shuttleworth said the font would be published under, which has yet to be specified much less applied to the release.

Canonical's Jorge Castro commented (the third comment on Kozheva's post) that the font was made available in a limited test because of its incompleteness, saying "font foundries who make fonts don't like beta fonts to spread because once they do they feel it's hard to track down who has the font and update that." He also addressed Kozheva's concern that the as-yet-undetermined license for the font would not be sufficiently free, noting Ubuntu's policy to ship only free software in the "main" Apt repository.

At one level, font foundry's reluctance to release pre-1.0 fonts for public consumption is understandable; no one enjoys widespread dissemination of buggy work. But the suggestion that fonts are intrinsically different from other software in this regard does not stand up to examination. After all, people have argued in the past that particular niches of software or types of project do not fit the standard "release early, release often" open source development model, and should be excused.

Those wanting to be excused tend to conjure up the same spectre: that early releases will confuse and frighten end users, hurting them and endangering the project. But that bogeyman ignores years of successful open source development in all areas of computing, and there are examples of successful projects for each niche claiming an exception.

To its credit, despite Castro's comment, Canonical does not seem to be motivated by a desire to keep the Ubuntu font secret prior to its official release — the CSS-based testing tool and call for bug reports are evidence enough of that. Rather, the fundamental issue is more likely to be that the font is a commissioned work from a third-party, and the company may not own it until it is delivered in final form by the contractor. That would be in line with Canonical's current lack of a license selection, but, apart from corporate lawyers, there is simply nothing to prevent the company from announcing what the license will be.

Context

Canonical's font commission from Dalton-Maag follows the pattern established by the Liberation and Droid font sets in years past. Both Liberation and Droid were commissioned by Linux distributions (Red Hat and Google's Android, respectively) from Ascender Corporation. Although both were released under open source licenses when complete — Liberation under the GPL with a font-embedding exception clause, and Droid under the Apache license — neither was made available for beta testing during its development.

The Open Font Library (OFLB) project's Dave Crossland said that he believes "libre fonts ought to be developed fully public from the start," but that in its historical context, the Ubuntu Beta program is a welcome innovation and ought to be applauded. To the best of his knowledge, he said, no proprietary font companies release beta testing versions of their fonts — although some custom fonts designed for print publications undergo ongoing revision, which has a similar effect regarding feedback from readers.

In addition, Crossland added that the CSS font testing web application deployed for the Ubuntu Beta font is itself an impressive development, and makes collecting rich bug reports easy.

Challenges for open font development

Fonts certainly can be developed in the open, as OFLB's library demonstrates. Practically speaking, however, most fonts released under open licenses are not developed using public source code repositories, version control systems, and issue trackers. Crossland observed that (apart from operating system default installs) fonts are historically installed by users as binaries, rather than through package repositories that facilitate updates. That has long been the case on proprietary operating systems, and is common practice for commercially-purchased and "free font" downloads by Linux users. "Instead we drag'n'drop binary files into system font folders by hand, and of course we never check back to see if there are updates for that font we installed and mostly forgot about." As a result, fonts do not receive the type of feedback from users that helps them to evolve.

Changing this development process is something that OFLB has been discussing in recent months, including planning for a revision to the project's public web site. Nicolas Spalinger, co-author of the Open Font License and member of the Debian pkg-fonts team, helped develop an "open font design toolkit" package now available in Debian and in Ubuntu that includes not just the design tools, but version control, diffing and patching utilities, and skeleton files for maintaining change logs.

Equally important to open font development is enabling users to make contributions. As it stands today, it is not easy for end users to contribute back to a font. Source code packages are available for several open fonts, but there is no packaging standard between distributions, and sometimes not even within a distribution. Some source packages contain .SFD sources for the font editor FontForge, for example, but not build or installation scripts. Ubuntu's graphical Apt front-ends Synaptic and Ubuntu Software Center do not even allow browsing or downloading source packages.

To non-developers — who constitute the largest group of potential font contributors — editing fonts remains effectively out-of-reach. It is not a hypothetical concern, either. Several readers commented on the Ubuntu Font Beta announcement that they would like to contribute additional characters or alphabets to the font; without some changes, it will be hard for them to do so.

Clearly, the challenge of opening up fonts to the same standards of software freedom common in other packages is not unique to Ubuntu or Debian. Other distributions are showing signs of taking the subject more seriously; Fedora, notably, has an active font Special Interest Group (SIG) packaging open fonts in binary and source form. While the "members only" beta program Canonical unveiled for its font commission raised some objections, it needs to be seen in context, as one small move on a longer trajectory of opening up fonts.

Comments (9 posted)

Page editor: Jonathan Corbet

Security

A trojan in a Firefox security add-on

There is an impressive list of Firefox security add-ons that makes up the Web Application Security Penetration Testing collection. It contains many of the most well-known addons (Firebug, Greasemonkey, etc.) along with a whole raft of lesser-known, but still useful add-ons—83 add-ons in all. Folks who install from the collection probably weren't expecting that it might also contain a trojan horse in the form of a password logger, but that's just what the "Mozilla Sniffer" add-on did, as Netcraft recently reported.

The add-on in question was marked as "experimental", which means that it had not undergone the code review that add-ons get before turning off the experimental flag. That flag should make users more wary about installing those add-ons, but since it came from the Mozilla web site, and was listed in the collection, it's not hard to see how users, even seemingly security-conscious ones, might get fooled into installing it. The malware author did try to misdirect users by stating that "the addon was validated by MOZILLA validation", but the download page clearly indicated that it had not been reviewed. In any case, some 1800 users downloaded it, and it was in daily use by 334 at the time it was discovered to be a trojan.

So, what did Mozilla Sniffer do? It didn't only "view and modify HTTP/HTTPS headers" as it claimed, but also checked each form that was submitted to see if there were password fields in the form. If so, it sent the form data, which would include the username and password, and the form destination URL off to a server that was presumably under the malware author's control. Essentially all credentials that were used while the add-on was installed were logged for whatever, undoubtedly nefarious, plan the attacker had.

Mozilla Sniffer was uploaded to addons.mozilla.org on June 6, but its trojan nature was not discovered until July 12. Johann-Peter Hartmann had installed some add-ons from the collection to do some security testing of an online game when he noticed a strange HTTP request being made when he logged into the game. Noticing that it sent the credentials and URL to some IP address he didn't recognize, he started to dig deeper.

Hartmann realized that one of the recently installed add-ons was likely to blame, so he started poking around in the source code for those, looking for the destination URL for the unexpected HTTP request. He found it in the popular (and reviewed by Mozilla) Tamper Data add-on, which was rather surprising. It turns out that Mozilla Sniffer had used Tamper Data's universally unique identifier (UUID) so it was able to overwrite the data in the Tamper Data directory—in effect masquerading as that add-on.

The add-on was quickly removed once Hartmann reported it to security@mozilla.org. Mozilla also put out a security announcement on the add-ons blog, but for a substantial number of users, the damage was already done. Mozilla Sniffer was added to Mozilla's add-on blocklist, which will cause users to be prompted to uninstall the add-on. That should remove the problem going forward, but it is likely that some credentials were sent off to the author's site so affected users should probably change any passwords they used after installing Mozilla Sniffer.

Mozilla is currently working on a proposal to change the add-on review process so that unreviewed add-ons are not available from addons.mozilla.org:

The new review process would essentially require all add-ons to get at least a preliminary, cursory code review for malicious code before it could appear on the site. Add-ons that had not passed that initial review would not appear when users searched or browsed add-ons. That would remove the implicit—though clearly disclaimed—Mozilla "stamp of approval" for unreviewed add-ons. Even those that pass the preliminary review will still be marked as "unverified" and be subject to a number of limitations (lowered search ranking, click-through warning on install, etc.).

The preliminary review is meant to get the add-on out in front of users fairly quickly so that developers can get feedback before requesting a full review. The full review will take longer, but passing it will give the add-on full privileges at the Mozilla add-on site.

While it is rather ugly for the users affected, the effects of the attack were not all bad. It should help lead to better procedures for reviewing add-ons as well as making it clearer what the limitations of the current review process are. The attack itself wasn't terribly sophisticated, so it would presumably have been detected immediately if a review had been requested. A more subtle attack, that might remain undetected even with a full review, would be much more dangerous.

In the end, installing an add-on requires some level of trust in the author. Reviewers can make mistakes, as can automated review tools. Since Mozilla does not do any vetting of the add-on authors, it would seem possible, likely even, that some day a determined attacker will slip something through Mozilla's review process. That will be a really bad day.

Comments (7 posted)

Brief items

Quote of the week

-- Kiwicon IV CFP

Comments (1 posted)

Adamski: Contextual Identity

Mozilla's Director of Security Engineering, Lucas Adamski, looks at privacy, identity, and security on his blog. "So maybe its not a surprise that many social networks have ended up with privacy egg in their face. Part of the problem is that by presuming that users should have only a single, canonical identity on their network (and indeed, often the entire web), they lack the flexibility for individuals to express their various identities appropriately in different contexts."

Comments (none posted)

Refresh of the Mozilla Security Bug Bounty Program

The Mozilla Security Blog has announced a refresh of the Mozilla security bug bounty. The amount awarded for bugs has gone from $500 to $3000, and bugs for Firefox Mobile and Mozilla services are explicitly included, along with other changes. "In concert with those changes, we are also updating the eligibility language to make it clear that Mozilla reserves the right to disqualify bugs from the bounty payment if the reporter has been deemed to have acted against the best interests of our users. To be very clear, we are not modifying our position regarding payment for publicly disclosed bugs; Mozilla bounty payments are not contingent upon confidential disclosure. While Mozilla strongly encourages researchers to disclose bugs to us privately (and most researchers have), we also believe that researchers should ultimately retain control over when and how the details of their research are disclosed."

Comments (2 posted)

Google: Rebooting responsible disclosure

The Google security blog is carrying a manifesto of sorts on how disclosure of security holes should be handled. "So, is the current take on responsible disclosure working to best protect end users in 2010? Not in all cases, no. The emotionally loaded name suggests that it is the most responsible way to conduct vulnerability research - but if we define being responsible as doing whatever it best takes to make end users safer, we will find a disconnect. We’ve seen an increase in vendors invoking the principles of 'responsible' disclosure to delay fixing vulnerabilities indefinitely, sometimes for years; in that timeframe, these flaws are often rediscovered and used by rogue parties using the same tools and methodologies used by ethical researchers. The important implication of referring to this process as 'responsible' is that researchers who do not comply are seen as behaving improperly. However, the inverse situation is often true: it can be irresponsible to permit a flaw to remain live for such an extended period of time."

Comments (18 posted)

New vulnerabilities

firefox et al: multiple vulnerabilities

Package(s):	firefox	CVE #(s):	CVE-2010-0654 CVE-2010-1206 CVE-2010-1207 CVE-2010-1208 CVE-2010-1209 CVE-2010-1210 CVE-2010-1212 CVE-2010-1213 CVE-2010-1215 CVE-2010-2752
Created:	July 21, 2010	Updated:	November 2, 2010
Description:	The firefox browser has been updated to fix yet another long list of scary-looking vulnerabilities.
Alerts:	Debian DSA-2124-1 2010-11-01 Mandriva MDVSA-2010:169 2010-09-02 MeeGo MeeGo-SA-10:12 2010-08-03 openSUSE openSUSE-SU-2010:0430-4 2010-08-23 SUSE SUSE-SA:2010:032 2010-07-30 openSUSE openSUSE-SU-2010:0430-3 2010-07-29 Debian DSA-2075-1 2010-07-27 openSUSE openSUSE-SU-2010:0430-2 2010-07-27 Ubuntu USN-958-1 2010-07-26 openSUSE openSUSE-SU-2010:0430-1 2010-07-26 Ubuntu USN-930-5 2010-07-23 Ubuntu USN-930-4 2010-07-23 Ubuntu USN-957-1 2010-07-23 Fedora FEDORA-2010-11361 2010-07-23 Fedora FEDORA-2010-11379 2010-07-23 Fedora FEDORA-2010-11361 2010-07-23 Fedora FEDORA-2010-11379 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11363 2010-07-23 Fedora FEDORA-2010-11327 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Red Hat RHSA-2010:0547-01 2010-07-20 Fedora FEDORA-2010-11345 2010-07-23 Slackware SSA:2010-202-01 2010-07-22 CentOS CESA-2010:0547 2010-07-22

Comments (none posted)

freetype: multiple vulnerabilities

Package(s):	freetype	CVE #(s):	CVE-2010-2497 CVE-2010-2498 CVE-2010-2499 CVE-2010-2500 CVE-2010-2519 CVE-2010-2520 CVE-2010-2527
Created:	July 15, 2010	Updated:	January 20, 2011
Description:	From the Debian advisory: Robert Swiecki discovered several vulnerabilities in the FreeType font library, which could lead to the execution of arbitrary code if a malformed font file is processed.
Alerts:	MeeGo MeeGo-SA-10:34 2010-10-09 MeeGo MeeGo-SA-10:33 2010-10-09 MeeGo MeeGo-SA-10:32 2010-10-09 MeeGo MeeGo-SA-10:31 2010-10-09 SUSE SUSE-SR:2010:016 2010-08-26 openSUSE openSUSE-SU-2010:0549-1 2010-08-25 Fedora FEDORA-2010-15705 2010-10-05 CentOS CESA-2010:0577 2010-08-16 CentOS CESA-2010:0578 2010-08-03 Pardus 2010-100 2010-08-02 Red Hat RHSA-2010:0578-01 2010-07-30 Red Hat RHSA-2010:0577-01 2010-07-30 Mandriva MDVSA-2010:137 2010-07-18 Debian DSA-2070-1 2010-07-14 Ubuntu USN-963-1 2010-07-20 Gentoo 201201-09 2012-01-23 SUSE SUSE-SU-2012:0553-1 2012-04-23

Comments (none posted)

mlmmj: directory traversal

Package(s):	mlmmj	CVE #(s):	CVE-2009-4896
Created:	July 21, 2010	Updated:	July 21, 2010
Description:	The mlmmj mailing list manager suffers from a directory traversal vulnerability exploitable by remote, authenticated attackers.
Alerts:	Debian DSA-2073-1 2010-07-20

Comments (none posted)

mozilla products: server spoofing

Package(s):	seamonkey firefox	CVE #(s):	CVE-2010-2751
Created:	July 21, 2010	Updated:	August 17, 2010
Description:	The seamonkey and firefox browsers contain a flaw in the location bar display which could be exploited to make it seem that arbitrary data originates from a secure server.
Alerts:	CentOS CESA-2010:0546 2010-08-16 SUSE SUSE-SA:2010:032 2010-07-30 openSUSE openSUSE-SU-2010:0430-3 2010-07-29 Debian DSA-2075-1 2010-07-27 openSUSE openSUSE-SU-2010:0430-1 2010-07-26 Ubuntu USN-930-5 2010-07-23 Ubuntu USN-930-4 2010-07-23 Ubuntu USN-957-1 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11363 2010-07-23 Fedora FEDORA-2010-11327 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Red Hat RHSA-2010:0547-01 2010-07-20 Red Hat RHSA-2010:0546-01 2010-07-20 CentOS CESA-2010:0547 2010-07-22

Comments (none posted)

openldap: denial of service

Package(s):	openldap	CVE #(s):	CVE-2010-0211 CVE-2010-0212
Created:	July 20, 2010	Updated:	November 1, 2010
Description:	From the Red Hat advisory: Multiple flaws were discovered in the way the slapd daemon handled modify relative distinguished name (modrdn) requests. An authenticated user with privileges to perform modrdn operations could use these flaws to crash the slapd daemon via specially-crafted modrdn requests. (CVE-2010-0211, CVE-2010-0212)
Alerts:	Fedora FEDORA-2010-11319 2010-07-23 SUSE SUSE-SR:2010:016 2010-08-26 openSUSE openSUSE-SU-2010:0546-1 2010-08-25 openSUSE openSUSE-SU-2010:0547-1 2010-08-25 Fedora FEDORA-2010-11343 2010-07-23 Ubuntu USN-965-1 2010-08-09 SUSE SUSE-SR:2010:014 2010-08-02 Debian DSA-2077-1 2010-07-29 Mandriva MDVSA-2010:142 2010-07-28 openSUSE openSUSE-SU-2010:0427-1 2010-07-26 CentOS CESA-2010:0542 2010-07-21 CentOS CESA-2010:0543 2010-07-21 Red Hat RHSA-2010:0543-01 2010-07-20 Red Hat RHSA-2010:0542-01 2010-07-20

Comments (none posted)

openoffice.org: Python macro security bypass

Package(s):	OpenOffice	CVE #(s):	CVE-2010-0395
Created:	July 16, 2010	Updated:	November 8, 2010
Description:	From the CVE entry: OpenOffice.org 2.x and 3.0 before 3.2.1 allows user-assisted remote attackers to bypass Python macro security restrictions and execute arbitrary Python code via a crafted OpenDocument Text (ODT) file that triggers code execution when the macro directory structure is previewed.
Alerts:	Mandriva MDVSA-2010:221 2010-11-05 SUSE SUSE-SR:2010:014 2010-08-02 openSUSE openSUSE-SU-2010:0386-1 2010-07-16

Comments (none posted)

pcsc-lite: privilege escalation

Package(s):	pcsc-lite	CVE #(s):	CVE-2009-4901 CVE-2009-4902
Created:	July 15, 2010	Updated:	September 24, 2010
Description:	From the Red Hat bugzilla entry: CVE-2009-4901: The MSGFunctionDemarshall function in winscard_svc.c in the PC/SC Smart Card daemon (aka PCSCD) in MUSCLE PCSC-Lite before 1.5.4 might allow local users to cause a denial of service (daemon crash) via crafted SCARD_SET_ATTRIB message data, which is improperly demarshalled and triggers a buffer over-read, a related issue to CVE-2010-0407. CVE-2009-4902: Buffer overflow in the MSGFunctionDemarshall function in winscard_svc.c in the PC/SC Smart Card daemon (aka PCSCD) in MUSCLE PCSC-Lite 1.5.4 and earlier might allow local users to gain privileges via crafted SCARD_CONTROL message data, which is improperly demarshalled. NOTE: this vulnerability exists because of an incorrect fix for CVE-2010-0407.
Alerts:	Mandriva MDVSA-2010:189-1 2010-09-24 Mandriva MDVSA-2010:189 2010-09-24 SUSE SUSE-SR:2010:015 2010-08-17 openSUSE openSUSE-SU-2010:0500-1 2010-08-12 Ubuntu USN-969-1 2010-08-05 Red Hat RHSA-2010:0533-01 2010-07-14 CentOS CESA-2010:0533 2010-07-15

Comments (none posted)

thunderbird: code execution

Package(s):	thunderbird	CVE #(s):	CVE-2010-1211 CVE-2010-1214 CVE-2010-2753
Created:	July 21, 2010	Updated:	January 21, 2011
Description:	Thunderbird suffers from a number of vulnerabilities associated with the processing of malformed HTML content; these could be exploited via a properly-crafted email message to execute arbitrary code.
Alerts:	MeeGo MeeGo-SA-10:24 2010-09-03 MeeGo MeeGo-SA-10:39 2010-10-09 SUSE SUSE-SA:2010:056 2010-11-08 openSUSE openSUSE-SU-2010:0906-1 2010-10-28 openSUSE openSUSE-SU-2010:0632-3 2010-10-11 openSUSE openSUSE-SU-2010:0632-2 2010-09-20 openSUSE openSUSE-SU-2010:0632-1 2010-09-17 Mandriva MDVSA-2010:173 2010-09-11 Mandriva MDVSA-2010:169 2010-09-02 openSUSE openSUSE-SU-2010:0430-4 2010-08-23 CentOS CESA-2010:0546 2010-08-16 Mandriva MDVSA-2010:147 2010-08-10 CentOS CESA-2010:0544 2010-08-06 Pardus 2010-102 2010-08-02 SUSE SUSE-SA:2010:032 2010-07-30 openSUSE openSUSE-SU-2010:0430-3 2010-07-29 Debian DSA-2075-1 2010-07-27 openSUSE openSUSE-SU-2010:0430-2 2010-07-27 Ubuntu USN-958-1 2010-07-26 openSUSE openSUSE-SU-2010:0430-1 2010-07-26 Ubuntu USN-930-5 2010-07-23 Ubuntu USN-930-4 2010-07-23 Ubuntu USN-957-1 2010-07-23 Fedora FEDORA-2010-11361 2010-07-23 Fedora FEDORA-2010-11379 2010-07-23 Fedora FEDORA-2010-11361 2010-07-23 Fedora FEDORA-2010-11379 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11363 2010-07-23 Fedora FEDORA-2010-11327 2010-07-23 SUSE SUSE-SA:2010:049 2010-10-12 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Red Hat RHSA-2010:0547-01 2010-07-20 Red Hat RHSA-2010:0546-01 2010-07-20 Red Hat RHSA-2010:0545-01 2010-07-20 CentOS CESA-2010:0547 2010-07-22 CentOS CESA-2010:0545 2010-07-22 Red Hat RHSA-2010:0544-01 2010-07-20

Comments (none posted)

thunderbird: information disclosure

Package(s):	thunderbird	CVE #(s):	CVE-2010-2754
Created:	July 21, 2010	Updated:	September 2, 2010
Description:	Thunderbird contains a "same origin bypass flaw" which could be used by remote HTML content to steal data from other HTML content.
Alerts:	Mandriva MDVSA-2010:169 2010-09-02 openSUSE openSUSE-SU-2010:0430-4 2010-08-23 CentOS CESA-2010:0546 2010-08-16 CentOS CESA-2010:0544 2010-08-06 Pardus 2010-102 2010-08-02 SUSE SUSE-SA:2010:032 2010-07-30 openSUSE openSUSE-SU-2010:0430-3 2010-07-29 Debian DSA-2075-1 2010-07-27 openSUSE openSUSE-SU-2010:0430-2 2010-07-27 Ubuntu USN-958-1 2010-07-26 openSUSE openSUSE-SU-2010:0430-1 2010-07-26 Ubuntu USN-930-5 2010-07-23 Ubuntu USN-930-4 2010-07-23 Ubuntu USN-957-1 2010-07-23 Fedora FEDORA-2010-11361 2010-07-23 Fedora FEDORA-2010-11379 2010-07-23 Fedora FEDORA-2010-11361 2010-07-23 Fedora FEDORA-2010-11379 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Fedora FEDORA-2010-11345 2010-07-23 Fedora FEDORA-2010-11363 2010-07-23 Fedora FEDORA-2010-11327 2010-07-23 Fedora FEDORA-2010-11375 2010-07-23 Red Hat RHSA-2010:0547-01 2010-07-20 Red Hat RHSA-2010:0546-01 2010-07-20 Red Hat RHSA-2010:0545-01 2010-07-20 Red Hat RHSA-2010:0544-01 2010-07-20 Fedora FEDORA-2010-11345 2010-07-23 Slackware SSA:2010-202-02 2010-07-22 CentOS CESA-2010:0547 2010-07-22 CentOS CESA-2010:0545 2010-07-22

Comments (none posted)

vte: arbitrary code execution

Package(s):	vte	CVE #(s):	CVE-2010-2713
Created:	July 16, 2010	Updated:	January 19, 2011
Description:	From the Ubuntu advisory: Janne Snabb discovered that applications using VTE, such as gnome-terminal, did not correctly filter window and icon title request escape codes. If a user were tricked into viewing specially crafted output in their terminal, a remote attacker could execute arbitrary commands with user privileges.
Alerts:	MeeGo MeeGo-SA-10:25 2010-09-03 Mandriva MDVSA-2010:161 2010-08-24 Pardus 2010-111 2010-08-11 SUSE SUSE-SR:2010:014 2010-08-02 openSUSE openSUSE-SU-2010:0423-1 2010-07-22 Ubuntu USN-962-1 2010-07-15 openSUSE openSUSE-SU-2010:0404-1 2010-07-20

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The current development kernel remains 2.6.35-rc5; no new -rc releases have been made over the last week. The stream of fixes into the mainline continues, though; there has also been a renaming of the logical memory block (LMB) code to "memblock." The -rc6 release can probably be expected shortly after LWN's publication time.

Stable updates: there have been no stable updates over the last week.

Comments (none posted)

Quote of the week

-- Andrew Morton

Comments (1 posted)

The ghost of sysfs past

A few years back, it seemed that incompatible sysfs changes created broken systems on a regular basis. Since then, though, things have gotten better, with no reports of broken systems or forced udev upgrades for a while. That improvement is the result of a deliberate effort on the part of the sysfs hackers to stabilize things and to establish best practices for the use of sysfs-exported information. As some linux-next testers are currently finding out, though, the legacy of older sysfs problems has not entirely faded away yet.

The CONFIG_SYSFS_DEPRECATED configuration option exists as one way of mitigating the effects of a major sysfs change. In the early days of sysfs, devices tended to pop up in strange places, including, especially, under /sys/class. In order to bring more consistency to the filesystem, the layout was reorganized to move more device information into /sys/devices, create the /sys/block directory, and more. Needless to say, any such change would be fatal for systems which expected the old layout, so the configuration option was added to restore that old layout when needed.

In 2010, nobody has shipped a distribution which relies on the old layout for some time. So Greg Kroah-Hartman has posted a patch to remove the configuration option and the significant amount of code needed to support it; that patch has also gone into linux-next. Greg notes: "This is no longer needed by any userspace tools, so it's safe to remove."

Except that maybe it's not safe to remove. Andrew Morton quickly reported that his Fedora Core 6 box would not boot without this option. Andrew is well known for running archaic distributions just for the purpose of finding this kind of compatibility issue; one might argue that there probably are not that many other FC6 boxes in use, and even fewer which will be wanting to run 2.6.35 kernels. But, as Dave Airlie noted, RHEL5 boxes will also fail to boot, and there are rather more of those in operation.

Dave's advice was blunt: "Live with your mistakes guys, don't try and bury them." He knows as well as anybody what the cost of living with mistakes is: the graphics ABIs include a few of their own. Mistakes will happen, but, when they become part of the user-space ABI, they can be difficult to get away from. That is why ABI additions tend to come under high levels of scrutiny: once somebody depends on them, they must be supported indefinitely.

Comments (19 posted)

Kernel development news

Fixing writeback from direct reclaim

"Writeback" is the process of writing the contents of dirty memory pages back to their backing store, where that backing store is normally a file or swap area. Proper handling of writeback is crucial for both system performance and data integrity. If writeback falls too far behind the dirtying of pages, it could leave the system with severe memory pressure problems. Having lots of dirty data in memory also increases the amount of data which may be lost in the event of a system crash. Overly enthusiastic writeback, on the other hand, can lead to excessive I/O bandwidth usage, and poorly-planned writeback can greatly reduce I/O performance with excessive disk seeks. Like many memory-management tasks, getting writeback right is a tricky exercise involving compromises and heuristics.

Back in April, LWN looked at a specific writeback problem: quite a bit of writeback activity was happening in direct reclaim. Normally, memory pages are reclaimed (made available for new uses, with data written back, if necessary) in the background; when all goes well, there will always be a list of free pages available when memory is needed. If, however, a memory allocation request cannot be satisfied from the free list, the kernel may try to reclaim pages directly in the context of the process performing the allocation. Diverting an allocation request into this kind of cleanup activity is called "direct reclaim."

Direct reclaim normally works, and it is a good way to throttle memory-hungry processes, but it also suffers from a couple of significant problems. One of those is stack overflows; direct reclaim can happen from almost anywhere in the kernel, so it may be that the kernel stack is already mostly used before the reclaim process even starts. But if reclaim involves writing file pages back, it can be just the beginning of a long call chain in its own right, leading to the overflow of the kernel stack. Beyond that, direct reclaim, which reclaims pages wherever it can find them, tends to create seek-intensive I/O, hurting the whole system's I/O performance.

Both of these problems have been seen on production systems. In response, a number of filesystems have been changed so that they simply ignore writeback requests which come from the direct reclaim code. That makes the problem go away, but it is a kind of papering-over that pleases nobody; it also arguably increases the risk that the system could go into the dreaded out-of-memory state.

Mel Gorman has been working on the reclaim problem, on and off, for a few months now. His latest patch set will, with luck, improve the situation. The actual changes made are relatively small, but they apparently tweak things in the right direction.

The key to solving a problem is understanding it. So, perhaps, it's not surprising that the bulk of the changes do not actually affect writeback; they are, instead, tracing instrumentation and tools which provide information on what the reclaim code is actually doing. The new tracepoints provide visibility into the nature of the problem and, importantly, how much each specific change helps.

The core change is deep within the direct reclaim loop. If direct reclaim stumbles across a page which is dirty, it now must think a bit harder about what to do with it. If the dirty page is an anonymous (process data) page, writeback happens as before. The reasoning here seems to be that the writeback path for these pages (which will be going to a swap area) will be simpler than it is for file-backed pages; there are also fewer opportunities for anonymous pages to be written back via other paths. As a result, anonymous writeback might still create seek problems - but only if the swap area shares a spindle with other, high-bandwidth data.

For dirty, file-backed pages, the situation is a little different; direct reclaim will no longer try to write back those pages directly. Instead, it creates a list of the dirty pages it encounters, then hands them over to the appropriate background process for the real writeback work. In some cases (such as when lumpy reclaim is trying to free specific larger chunks of memory), the direct reclaim code will wait in the hope that the identified pages will soon become free. The rest of the time, it simply moves on, trying to find free pages elsewhere.

Handing the reclaim work over to the threads which exist for that task has a couple of benefits. It is, in effect, a simple way of switching to another kernel stack - one which is known to be mostly empty - before heading into the writeback paths. Switching stacks directly in the direct reclaim code had been discussed, but it was decided that the mechanism the kernel already has for switching stacks (context switches) was probably the right thing to use in this situation. Keeping the writeback work in kswapd and the per-BDI writeback threads should also help performance, since those threads try to order operations to minimize head seeks.

When this problem was discussed in April, Andrew Morton pointed out that, over time, the amount of memory written back in direct reclaim has grown significantly, with an adverse effect on system performance. He wanted to see thought put into why that change has happened rather than trying to mitigate its effects. The final patch in Mel's series looks like an attempt to address this concern. It changes the direct reclaim code so that, if that code starts encountering dirty pages, it pokes the writeback threads and tells them to start cleaning pages more aggressively. The idea here is to keep the normal reclaim mechanisms running at a fast-enough pace that direct reclaim is not needed so often.

This tweak seems to have a significant effect on some benchmarks; Mel says:

Anybody who likes digging through benchmark results is advised to look at Mel's patch posting - he appears to have run just about every test that he could to quantify the effects of this patch series. This kind of extensive benchmarking makes sense for deep memory management changes, since even small changes can have surprising results on specific workloads. At this point, it seems that the changes have the desired effect and most of the concerns expressed with previous versions have been addressed. The writeback changes, perhaps, are getting ready for production use.

Comments (9 posted)

Adding periods to SCHED_DEADLINE

The Linux scheduler, in both the mainline and realtime versions, provides a couple of scheduling classes for realtime tasks. These classes implement the classic POSIX priority-based semantics, wherein the highest-priority runnable task is guaranteed to have access to the CPU. While this scheduler works as advertised, priority-based scheduling has a number of problems and has not been the focus of realtime research for some time. Cool schedulers in this century are based on deadlines instead. Linux does not yet have a deadline scheduler, though there is one in the works. A recent discussion on implementing the full deadline model has shown, once again, just how complex it can be to get deadline scheduling right in the real world.

Deadline scheduling does away with priorities, replacing them with a three-parameter tuple: a worst-case execution time (or budget), a deadline, and a period. In essence, a process tells the scheduler that it will require up to a certain amount of CPU time (the budget) by the given deadline, and that the deadline optionally repeats with the given period. So, for example, a video-processing application might request 1ms of CPU time to process the next incoming frame, expected in 10ms, with a 33ms period thereafter for subsequent frames. Deadline scheduling is appealing because it allows the specification of a process's requirements in a natural way which is not affected by any other processes running in the system. There is also great value, though, in using the deadline parameters to guarantee that a process will be able to meet its deadline, and to reject any process which might cause a failure to keep those guarantees.

The SCHED_DEADLINE scheduler being developed by Dario Faggioli appears to be on track for an eventual mainline merger, though nobody, yet, has been so foolish to set a deadline for that particular task. This scheduler works, but, thus far, it takes a bit of a shortcut: in SCHED_DEADLINE, the deadline and the period are assumed to be the same. This simplification makes the "admission test" - the decision as to whether to accept a new SCHED_DEADLINE task - relatively easy. Each process gets a "bandwidth" parameter, being the ratio of the CPU budget to the deadline/period value. As long as the sum of the bandwidth values for all processes on a given CPU does not exceed 1.0, the scheduler can guarantee that the deadlines will be met.

As Dario recently brought up on linux-kernel, there are users who would like to be able to specify separate deadline and period values. Adjusting the scheduler to implement those semantics is not particularly hard. Coming up with an admission test which insures that deadlines can still be met is rather harder, though. Once the period and the deadline are separated from each other, it becomes possible for processes to miss their deadlines even if the total bandwidth of the CPU has not been oversubscribed.

To see how this might come about, consider an example posted by Dario. Imagine a process which needs 4ms of CPU time with a period of 10ms and a deadline of 5ms. A timeline of how that process might be scheduled could look like this:

Here, the scheduler is able to run the process within its deadline; indeed, there is 1ms of time to spare. Now, though, if a second process comes in with the same set of requirements, the results will not be as good:

Despite the fact that 20% of the available CPU time remains unused, process P2 will miss its deadline by 3ms. In a hard realtime situation, that tardiness could prove fatal. Clearly, the scheduler should reject P2 in this situation. The problem is that detecting this kind of problem is not easy, especially if the scheduler is (as seems reasonable) expected to leave some CPU time for applications and not use it all performing complex admission calculations. For this reason, admission decision algorithms are currently an area of considerable research interest in the academic realtime community. See this paper by Alejandro Masrur et al. [PDF] or this one by Marko Bertogna [PDF] for examples of how involved it can get.

There are a couple of ways to simplify the problem. One of those would be to change the bandwidth calculation to be the ratio of the CPU budget to the relative deadline time (rather than to the period). For the example processes shown above, each has a bandwidth of 0.8 using this formula; the scheduler, on seeing that the second process would bump the total to 1.6, could then decide to reject it. Using this calculation, the scheduler can, once again, guarantee that deadlines will be met, but at a cost: this formula will cause the rejection of processes that, in reality, could be scheduled without trouble. It is an overly pessimistic heuristic which will prevent full utilization of the available resources.

An alternative, proposed by Dario, would be to stick with the period-based bandwidth values for admission decisions and to take the risk that some deadlines might not be met. In this case, user-space developers would be responsible for ensuring that the full set of tasks on the system can be scheduled. They might take some comfort in the fact that, since the overall bandwidth of the CPU would still not be oversubscribed, the amount by which a deadline could be missed would be deterministically bounded.

That idea did not survive its encounter with Peter Zijlstra, who thinks it ruins everything that a deadline scheduler is supposed to provide:

Peter's suggestion, instead, was to split deadline scheduling logically into two different schedulers. The hard realtime scheduler would retain the highest priority, and would require that the deadline and period values be the same. If, at some future time, a suitable admission controller is developed then that requirement could be relaxed as long as deadlines could still be guaranteed.

Below the hard realtime scheduler would be a soft realtime scheduler which would have access to (most of) the CPU bandwidth left unused by the hard scheduler. That scheduler could accept processes using period-based bandwidth values with the explicit understanding that deadlines might be missed by bounded amounts. Soft realtime is entirely good enough for a great many applications, so there is no real reason not to provide it as long as hard realtime is not adversely affected.

So that is probably how things will go, though the real shape of the solution will not be seen until Dario posts the next version of the SCHED_DEADLINE patch. Even after this problem is solved, though, deadline scheduling has a number of other challenges to overcome, with good multi-core performance being near the top of the list. So, while Linux will almost certainly have a deadline scheduler at some point, it's still hard to say just when that might be.

(Readers who are interested in the intersection of academic and practical realtime work might want to peruse the recently-released proceedings [PDF] from the OSPERT 2010 conference, held in Brussels in early July.)

Comments (21 posted)

Contiguous memory allocation for drivers

Allocation of physically-contiguous memory buffers is required by many device drivers, but it cannot always be reliably done on long-running Linux systems. That leads to all kinds of unsatisfying workarounds in driver code. The contiguous memory allocator patches recently posted by Michal Nazarewicz are an attempt to solve this problem in a consistent way for all drivers.

A few years ago, when your editor was writing the camera driver for the original OLPC XO system, a problem turned up. The video acquisition hardware on the system was capable of copying video frames into memory via DMA operations, but only to physically contiguous buffers. There was, in other words, no scatter/gather DMA capability built into this (cheap) DMA engine. A choice was thus forced: either allocate memory for video acquisition at boot time, or attempt to allocate it on the fly when the camera is actually used. The former choice is reliable, but it has the disadvantage of leaving a significant chunk of memory idle (on a memory-constrained system) whenever the camera is not in use - most of the time on most systems. The latter choice does not waste memory, but is unreliable - large, contiguous allocations are increasingly hard to do as memory gets fragmented. In the OLPC case, the decision was to sacrifice the memory to ensure that the camera would always work.

This particular problem has been faced many times by many developers over the years; each driver author has tended to go with whatever ad hoc solution seems to make sense at the time. For some years, the "bigphysarea" patch was available to help, but that patch was never put into the mainline and has not seen any maintenance for some time. So the problem remains unsolved in any sort of general sense.

The contiguous memory allocation (CMA) patches are an attempt to put together a flexible solution which can be used in all drivers. The basic technique will be familiar: CMA grabs a chunk of contiguous physical memory at boot time (when it's plentiful), then doles it out to drivers in response to allocation requests. Where it differs is mainly in an elaborate mechanism for defining the memory region(s) to reserve and the policies for handing them out.

A system using CMA will always need to have at least one boot-time parameter describing the memory region(s) to use and the policy for allocating from those regions. The syntax used is rather complex, to the point that a large portion of the patch is made up of parsing code; see the included Documentation/cma.txt file for the full details. A simple example of a CMA command-line option would be something like:

    cma=c=10M cma_map=camera=c

This defines a 10MB region (called "c") and states that allocation requests from the camera device should be satisfied from this region. Multiple regions can be defined, each with its own size, alignment constraints, and allocation algorithm, and memory regions can be split into different "kinds" as well. The "kinds" feature might be used to separate large and small allocations, or to put different buffers into different DMA zones or NUMA nodes. The more complex command lines are reminiscent of regular expressions, but with less readability. The purpose behind this complexity is to enable a great deal of flexibility in how memory is handled without the need to change the drivers which are working with that memory. Whether that flexibility is worth the cost is not (to your editor, at least) entirely clear.

A driver can actually allocate a memory chunk with:

    #include <linux/cma.h>

    unsigned long cma_alloc(const struct device *dev, const char *kind,
	     		    unsigned long size, unsigned long alignment);

If all goes well, the return value will be the physical address of the allocated memory region.

For reasons which are not entirely clear, buffers allocated with CMA have a reference count associated with them. So two functions are provided to manipulate that count:

    int cma_get(unsigned long addr);
    int cma_put(unsigned long addr);

Since reference counting is used, there is no cma_free() function; instead, the memory chunk is passed to cma_put() and freed internally when the reference count goes to zero.

CMA comes with a best-fit allocator, but it is designed to work with multiple internal allocators. So, should there be a need to use a different allocation algorithm, it's a really straightforward matter to add it to the system. Naturally enough, the command-line syntax offers a way to specify which allocator should be used for each region.

In summary: CMA offers a solution to a problem which driver authors have been dealing with for some years. Your editor suspects, though, that it will require some changes before a mainline merge can be contemplated. The complexity of the solution is probably more than is really called for in this situation, and the whole thing might benefit from some integration with the DMA mapping infrastructure. But, someday, it would be nice to incorporate a solution to the large-buffer problem that all drivers can use.

Comments (15 posted)

Patches and updates

Core kernel code

• Paul E. McKenney: RCU commits queued for 2.6.36/7 . (July 18, 2010)

• Tomasz Buchert: Wall time clocks + change in access rules . (July 19, 2010)

• Ai Li: cpuidle: extend cpuidle and menu governor to handle dynamic states . (July 19, 2010)

• Patrick Pannuto: timer: Added usleep[_range][_interruptible] timer . (July 20, 2010)

• Venkatesh Pallipadi: Finer granularity and task/cgroup irq time accounting . (July 20, 2010)

• stefani@seibold.net: enhanced reimplemention of the kfifo API . (July 20, 2010)

• Tejun Heo: workqueue: replace slow-work with workqueue . (July 21, 2010)

• Paul E. McKenney: rcu: Add a TINY_PREEMPT_RCU . (July 21, 2010)

Device drivers

• Tom Lyon: VFIO driver: Non-privileged user level PCI drivers . (July 18, 2010)

• Marc Kleine-Budde: CAN: Add Flexcan CAN controller driver . (July 19, 2010)

• Alan Cox: I2C driver supporting Moorestown and Medfield platform . (July 19, 2010)

• Laurent Pinchart: Media controller (core and V4L2) . (July 19, 2010)

• Matti J. Aaltonen: WL1273 FM Radio driver . (July 19, 2010)

• Janusz Krzysztofik: [PATCH 0/6] Add camera support to the OMAP1 Amstrad Delta videophone . (July 19, 2010)

• dd diasemi: GPIO: GPIO Driver for DA9052 PMIC . (July 20, 2010)

• Mattia Jona-Lasinio: Introducing the LCD-Linux project . (July 21, 2010)

Filesystems and block I/O

• David Howells: Extended file stat functions [ver #6] . (July 18, 2010)

• Vivek Goyal: cfq-iosched: Implement group idle V2 . (July 19, 2010)

• Aneesh Kumar K.V: Generic name to handle and open by handle syscalls . (July 19, 2010)

• Artem Bityutskiy: kill unnecessary bdi wakeups + cleanups . (July 21, 2010)

Memory management

• Nitin Gupta: zcache: page cache compression support . (July 18, 2010)

• Andrea Arcangeli: Transparent Hugepage Support #28 . (July 18, 2010)

• Mel Gorman: Reduce writeback from page reclaim context V4 . (July 19, 2010)

• David Rientjes: oom: badness heuristic rewrite . (July 19, 2010)

• Michal Nazarewicz: The Contiguous Memory Allocator . (July 20, 2010)

Networking

• Michael S. Tsirkin: netfilter: add CHECKSUM target . (July 18, 2010)

Architecture-specific

• Jeremy Fitzhardinge: X86 ticket lock cleanups and improvements . (July 18, 2010)

• Suresh Siddha: x86: xsaveopt kernel enabling patches - v2 . (July 20, 2010)

• Yinghai Lu: Use memblock with x86 . (July 20, 2010)

Security-related

• John Johansen: AppArmor security module . (July 18, 2010)

• Tetsuo Handa: LSM hook for post recvmsg. . (July 19, 2010)

Virtualization and containers

• Gleb Natapov: KVM: Add host swap event notifications for PV guest . (July 19, 2010)

Miscellaneous

• Pablo Neira Ayuso: libnetfilter_log 1.0.0 release . (July 19, 2010)

• Pablo Neira Ayuso: libnetfilter_conntrack 0.0.102 release . (July 19, 2010)

• Pablo Neira Ayuso: conntrack-tools 0.9.15 released . (July 19, 2010)

Page editor: Jonathan Corbet

Distributions

News and Editorials

REMnux 1.0: the malware analyst's playground

Security consultant Lenny Zeltser recently released the first version of REMnux, a Linux distribution that is specifically designed for malware analysis. For this purpose, the distribution includes some open source tools for analyzing and reverse engineering Flash malware, obfuscated JavaScript, shell code, malicious PDF files, and so on. The idea is to install REMnux in a virtual machine and then analyze the malware in its isolated environment.

Zeltser is an expert in malware analysis, and he is giving a course on Reverse-Engineering Malware at the SANS Institute. Because students of his course were asking him which tools to use, he put them all together into a collection that became REMnux:

To create the VMware virtual appliance of REMnux, Zeltser installed Ubuntu 9.10 in a VMware virtual machine, removed unnecessary packages, added the tools he liked, and customized the setup. To create the live CD version of the distribution, he used Remastersys.

In addition to its home page on Zeltser's web site, REMnux also has a SourceForge page with some discussion forums. The distribution can be downloaded as a 575 MB compressed VMware image or a 602 MB ISO file. The VMware image is the preferred version, as it is the only one that has undergone extensive testing, but your author used the ISO image as a live CD in VirtualBox without any big problems.

REMnux is a trimmed-down version of Ubuntu 9.10 with a hand-picked set of useful malware analysis tools. It starts up in a text-only console mode, and automatically logs in the user "remnux". An X environment can be launched with startx. The user is then greeted by the Enlightenment window manager and a terminal window. REMnux is configured to automatically acquire an IP address using DHCP.

The ~/.bash_aliases file contains various shortcuts to the most commonly-used tools, and additional tools can be installed from the Ubuntu software repository using apt-get. There are some imperfections, though, at least in the ISO version of REMnux. For instance, when firing up sshd, it turned out that the distribution hadn't set up SSH host keys, so you can only log into REMnux via SSH after creating the host keys manually:

    sudo ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ''
    sudo ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ''

According to Zeltser, this is a problem specific to the ISO version.

Analyze this

Adobe Flash malware in SWF files can be analyzed thanks to three tools: SWFTools, Flasm, and Flare. SWFTools is a collection of utilities for working with Adobe Flash files, and some of them are extremely valuable while analyzing malware, such as SWFStrings that scans for text data, and SWFDump that shows information such as a disassembly of contained code. Flasm is a SWF disassembler and assembler, and Flare is a SWF decompiler that converts the Flash byte code to ActionScript source code, which is interesting if the analyst wants to understand how a specific piece of malware works.

As most JavaScript malware is obfuscated to thwart analysis attempts, deobfuscation tools are really helpful. REMnux installs Firefox with some relevant extensions like the web development tool Firebug, the extension NoScript to selectively enable or disable malicious JavaScript files, a User Agent Switcher to fool malicious web sites, and JavaScript Deobfuscator that can handle scripts that are obfuscated and generated on-the-fly. There are also some stand-alone programs to help with deobfuscation, such as the Rhino debugger, the SpiderMonkey JavaScript engine, Windows Script Decoder, and Jsunpack-n.

REMnux has also some tools for malicious PDF analysis, such as the Origami framework, which is a Ruby library to parse, analyze and create PDF documents, and pdftk, which can merge, split, decrypt, unpack, repair, and do a lot of other things with PDF files. Last but not least, REMnux includes the PDF tools that security expert Didier Stevens wrote: pdf-parser.py that parses a PDF document and can search for a specific string, make-pdf-javascript.py that can embed JavaScript in a PDF document, and pdfid.py that scans a PDF document for different types of keywords, allowing the analyst to identify documents that contain (possibly malicious) JavaScript code or actions.

An interesting description of a real-world analysis of PDF malware was published recently at The H in its CSI:Internet series: PDF time bomb. The author describes how he received an email with a PDF attachment that crashed his Adobe Reader. After discovering that it was a suspicious file, he saw that the contents were compressed so that he couldn't see what's inside (a PDF file can simply be opened in a text editor, as it is somewhat human-readable, but fragments can be compressed). So he uncompressed the file with pdftk:

    pdftk NTFS-internals.pdf output plain.txt uncompress

After the contents of the PDF file were uncompressed, he discovered a lot of obfuscated JavaScript. To learn what it does, he copied all JavaScript fragments to a file and ran the code in SpiderMonkey, after commenting out the code that looks dangerous. In the end, he discovered that the code in the PDF file has a complete repertoire of exploits that are chosen based on the version of Adobe Reader the user is running. Ultimately, the malware will download and execute a keylogger. This scenario would be an excellent use-case for REMnux, and the author of the article could have used the PDF tools by Didier Stevens. With pdfid.py, he could have seen immediately how many JavaScript blocks and open actions the PDF file contains, including how many of these scripts are obfuscated by using alternative character encodings.

Networks and shell code

But REMnux is not limited to analyzing malware files. To analyze malicious IRC bots there is an IRC server (InspIRCd) and an IRC client (Irssi). For general network monitoring, REMnux offers the network protocol analyzer Wireshark. There are also a couple of tools that simulate network hosts with arbitrary services, which comes in handy when analyzing the behavior of malware in networks: Honeyd, INetSim, and fakedns. Specifically for web traffic, there is the web server Tiny HTTPd to investigate HTTP traffic, and the Paros HTTP proxy to intercept and modify all HTTPS and HTTPS data between a web server and client.

To analyze Linux shell code (machine code that is typically the payload of an exploit), REMnux users have various power tools at their disposal. There's the good old GDB debugger, the objdump disassembler (from GNU binutils), the hex editor and disassembler radare, and shellcode2exe that converts shell code that is encoded as a string to an executable file that can be loaded into a debugger to examine. And there's also the Volatility framework, which is a collection of Python tools that are able to extract information from RAM, crash dumps, and copies of hibernation files.

Because many malicious executable files are compressed, encrypted, or otherwise obfuscated, there are some tools to deal with this kind of "protection" or at least give some information about the methods used: UPX can compress and uncompress executable files, packerid.py detects the kind of compression, encryption, and compiler used in Windows PE files, Bytehist that shows a histogram of the usage of byte values, XORSearch that searches for a given string encoded with XOR, ROL, or ROT, and TrID that identifies file types from their binary signatures.

With all these interesting tools, it's a little disappointing that users have to consult the home page of REMnux to know which tools the distribution offers. Some of the tools, like Wireshark and Firefox are listed in Enlightenment's application menu, but the bulk of them aren't. The distribution could take a look at BackTrack for an example of a well-organized application menu. REMnux compensates this partially with the customized ~/.bash_aliases, which contains aliases for some of the tools (for example alias irc='irssi' and alias honeyd='sudo invoke-rc.d honeyd'), as well as some convenient aliases such as myip for the current IP address, but it still isn't quite the same.

Conclusion

Apart from the home page of the project, there's no documentation about REMnux, but this is not really necessary. It's more about the tools and what you can do with them than about the distribution. Zeltser does offer an overview article about how you set up a controlled malware analysis lab. While you could certainly use any general-purpose Linux distribution and install all the tools you need, REMnux offers a convenient pre-chosen collection of malware analysis tools, though there are a few minor imperfections that are typical for a 1.0 release.

Comments (2 posted)

New Releases

openSUSE 11.3 has been released

openSUSE 11.3 has been released and you can visit the product highlights page for a detailed list of new features. "The openSUSE Project is pleased to announce the release of the latest incarnation of openSUSE, with support for 32-bit and 64-bit systems. openSUSE 11.3 is packed with new features and updates including SpiderOak to sync your files across the Internet for free, Rosegarden for free editing of your audio files, improved indexing with Tracker, and updates to Mozilla Firefox, and Thunderbird. [...] Among these many new features, openSUSE also provides support for netbooks and the Btrfs file system support. Users can expect to see improved hardware support with the 2.6.34 Linux kernel and updated graphics drivers." Click below for the full announcement.

Full Story (comments: none)

PC-BSD 8.1 Released

The PC-BSD Team has announced the availability of PC-BSD 8.1 (Hubble Edition), running FreeBSD 8.1-RELEASE, and KDE 4.4.5. "Version 8.1 contains a number of enhancements and improvements. For a full list of changes, please refer to the changelog."

Comments (none posted)

Fixstars to Release "Yellow Dog Linux for CUDA"

Fixstars has announced the release of both an updated and a LiveDVD version of Yellow Dog Linux for NVIDIA CUDA v6.2.1. "Yellow Dog Linux for NVIDIA CUDA v6.2.1 bundles NVIDIA's CUDA SDK 3.1 and the updated packages found in RHEL/Centos 5.5. A whole host of other improvements and bug fixes have been made, including improved Intel chipset support, simplified NVIDIA toolkit version switching, as well as several improvements to Fixstars' CUDA Plugin for Eclipse."

Full Story (comments: none)

Distribution News

Quote of the week

-- Stephen Smoogen

Comments (none posted)

Debian GNU/Linux

Debian CD Project

The Debian CD Project, a non-profit independent project that promotes the use of Debian GNU/Linux, is shipping Debian "lenny" 5.0.5 CDs worldwide.

Comments (3 posted)

Fedora

Duffy: Fedora Board Meeting, 16 July 2010

Máirín Duffy looks at the July 16, 2010 meeting of the Fedora Advisory Board. "The board meeting today experimented with a different format than previous meetings. Rather than having a separate #fedora-board-questions channel, we allowed everyone voice in #fedora-board-meeting and had an open discussion. We started with Q&A upfront and then decided about halfway to make the entire meeting Q&A."

Comments (none posted)

Newsletters and articles of interest

Distribution newsletters

• DistroWatch Weekly, Issue 363 (July 19)
• Fedora Weekly News Issue 234 (July 14)
• openSUSE Weekly News, Issue 132 (July 18)
• Ubuntu Weekly Newsletter #202 (July 17)

Comments (none posted)

Damn Vulnerable Linux - The most vulnerable and exploitable operating system ever! (Geek.com)

Geek.com looks at Damn Vulnerable Linux (DVL). "Usually, when installing a new operating system the hope is that it's as up-to-date as possible. After installation there's bound to be a few updates required, but no more than a few megabytes. Damn Vulnerable Linux is different, it's shipped in as vulnerable a state as possible. The idea behind DVL is to offer an operating system for learning and research for security students."

Comments (6 posted)

Linux Distro Review: Mandriva Spring 2010.1 (Linux.com)

Joe 'Zonker' Brockmeier takes a look at Mandriva's latest release. "Mandriva is a bit of a standout among Linux distributions. It doesn't quite fit with the community distributions, and it doesn't quite fit with the corporate distros either. Mandriva provides a free distribution on DVD that's all open source software, and a PowerPack edition that contains some proprietary software like support for non-free multimedia codecs. The business model that Mandriva has pursued over the past 10 years hasn't been particularly successful - the company has been through bankruptcy once and has been having financial problems again recently. But the company does provide a solid and user-friendly Linux distro. To test out Mandriva 2010.1, I grabbed the DVD for x86 and gave it a spin. Mandriva also provides a live CD version, but I wanted to try out GNOME, KDE, and LXDE."

Comments (none posted)

openSUSE 11.3: The Linux Lizard Lives (ZDNet)

Jason Perlow reviews openSUSE 11.3 on ZDNet. "I've put the OS through its paces for the last several days and I have to say that while I continue to be impressed with the functionality of openSUSE, I'm not seeing a huge amount of sexy in the latest release. At best, I'd call openSUSE 11.3 a bug fix/service pack for 11.2 and 11.1. There are a few new features, most of which are under the hood, but from an end-user perspective there isn't a heck of a lot of new stuff to see here."

Comments (none posted)

What's new in openSUSE 11.3 (The H)

The H takes a look at openSUSE 11.3. "Another option has been added to the desktop selection. In addition to the classical KDE, GNOME and Xfce, the developers have now also integrated the lean LXDE desktop. To ensure optimum integration into openSUSE, the developers extended LXDE's PCManFm file manager to include a waste bin and GVFS support."

Comments (none posted)

Page editor: Rebecca Sobol

Development

StatusNet releases a desktop client

Finding a good microblogging client to support Twitter and Facebook is easy. Finding support for Identi.ca and other microblogging sites powered by StatusNet is a little more tricky outside the Linux desktop. For users on other platforms, StatusNet has taken matters into its own hands and released StatusNet Desktop, a multi-platform client that supports Identi.ca and StatusNet sites.

For those who are not knee-deep into social media, StatusNet is a free software, federated, microblogging platform. Like Twitter, StatusNet allows users to post short status updates — usually 140 characters long, but this is configurable for those running private or hosted installs of StatusNet. As a federated platform, StatusNet lets users communicate between different sites running StatusNet, removing the single point of control (and failure) present with Twitter and Facebook. StatusNet the company has been offering commercial support for the microblogging platform, and offering hosted instances to companies that want their own microblogging sites. However, to be successful, users need to be able to find decent client software for StatusNet that compares to the third-party clients for Twitter.

Since Identi.ca's user base isn't even a tenth of Twitter's, support for StatusNet has not been a high priority for developers behind popular microblogging clients like TweetDeck, CoTweet, Seesmic, and others. You can find applications for other platforms but Identi.ca/StatusNet is definitely not as well-loved as Twitter.

The Linux desktop is probably not the primary focus for StatusNet Desktop, and it doesn't really bring anything new to the table for Linux users. Identi.ca and StatusNet users are well-handled already by Gwibber, Choqok, and other microblogging clients for Linux. But Identi.ca and StatusNet are not well-supported by Windows and Mac OS X tools. Popular tools either lack Identi.ca support altogether or have have rudimentary support that requires workarounds to enable Identi.ca or StatusNet accounts.

The application is written with Appcelerator Titanium, an Apache-licensed open source platform for building desktop and mobile applications using HTML, CSS, and JavaScript in Python, PHP, or Ruby. Appcelerator is a relatively new platform for writing software for multiple desktop and mobile platforms. It's supposed to be similar to Adobe Air, but entirely open source. The StatusNet client is based on the Tweetanium Twitter client written by the Appcelerator team as a demo of the platform. Installers for StatusNet Desktop are provided for 32-bit and 64-bit Linux, as well as Mac OS X and Windows. The client is licensed under the Apache license as well, and is available on Gitorious.

Installing StatusNet Desktop on Linux is fairly easy. Just uncompress the tarball and run the StatusNet Desktop executable. It will offer to install in the local directory or under /opt for system-wide use.

The StatusNet Desktop client isn't without bugs on Linux. After running the installer, the application crashed immediately. A quick search on the wiki found a description of the problem and the resolution. The client also crashed a few times during testing. Most of the time it was fine, though.

StatusNet Desktop is a decent, but basic, microblogging client. It doesn't support some features you'll find in the Web application, such as geolocation support. It also doesn't provide support for viewing groups, a unique feature on Identi.ca and StatusNet microblogs that allows users to see messages that were sent by other group members that they don't subscribe to directly. Nor does it offer lists to watch a subset of the users that you follow, something Tweetdeck and other Twitter clients do well. At least at this stage, it is not a power-user's microblogging tool. Annoyingly, it will only pull up the last 25 posts from the users that you follow, so if you haven't looked at your personal timeline recently, you'll still need to visit the Web site to see a longer history.

Many Identi.ca users are also Twitter users, but they won't be posting to Twitter using the StatusNet Desktop application anytime soon. In a reply to the request for Twitter support on the StatusNet blog, StatusNet founder Evan Prodromou replied that there was no need to write another Twitter client, seeing as users could find hundreds of Twitter desktop clients. This may be true, but at least this user would prefer to use a single application to manage all of the accounts, rather than maintaining two (or more) clients to post to Twitter, Identi.ca, and other social networks. If the idea is to drive adoption of Identi.ca and StatusNet, it might not be a bad idea to also bundle Twitter support in the StatusNet Desktop to help support users with multiple accounts.

Linux users who want a Identi.ca client will probably do better to choose another more full-featured microblogging application with support for multiple networks. But the introduction of an official StatusNet client for Windows, Mac OS X, and (eventually) the most popular smartphone OSes may help drive adoption of StatusNet with users on those platforms. In particular, it may help drive adoption of the StatusNet platform by large organizations that would like to rebrand the desktop client. Lead developer Zach Copely says in a recent post on the StatusNet blog that it is a response to StatusNet's customers' needs, more than an offering that is needed by the open source community.

Copely also points out that, while some third-party applications offer StatusNet support, no one is really focusing on the software. A dedicated client allows the company to find bugs in the APIs offered by StatusNet and make sure it works well:

So far the development has been handled by StatusNet. Now that it's released, one hopes it will be extended by the StatusNet-using community to take full advantage of the platform and perhaps work with other networks. Discussion for development is handled on the StatusNet-dev mailing list. The final verdict on StatusNet Desktop is that it's a competent microblogging application that works well with StatusNet, but doesn't yet offer much compelling beyond what's available with Gwibber, Chokoq, and others.

Comments (none posted)

Brief items

Quotes of the week

-- Ingy döt Net

-- Mark Engelberg

Comments (1 posted)

GroupServer 1.0beta2

GroupServer is a mailing list management system: "GroupServer works like traditional mailing list managers but it also has a web forum interface for reading and making posts, and list administration." The second 1.0 beta release is now available, with the final release coming in the near future.

Full Story (comments: 2)

Hatta 1.4.0 wiki engine released

Hatta 1.4.0 is a simple wiki engine meant to be run from a Mercurial repository. "It's mostly for small development teams to use for documentation of the project right in the repository. It's mostly a plain, traditional wiki, without fancy features to distract from doing real work." New features in the just-announced 1.4.0 release include image thumbnails, Mercurial 1.6 compatibility, and more.

Full Story (comments: none)

Mozilla releases new versions of Firefox and Thunderbird

Mozilla has announced the release of Firefox 3.6.7 and Firefox 3.5.11, and Thunderbird 3.1.1 and Thunderbird 3.0.6. These releases fix several security and stability issues. See the release notes for details: Firefox 3.6.7, Firefox 3.5.11, Thunderbird 3.1.1, and Thunderbird 3.0.6.

Update: the SeaMonkey 2.0.6 release is also now available.

Comments (16 posted)

Introducing OpenStack

The OpenStack project has announced its existence; its goal is to create a free (Apache 2.0), scalable infrastructure for cloud computing. "Today, OpenStack consists of two projects. The first is a fully distributed object store based on Rackspace's Cloud Files offering called 'OpenStack Object Storage'. The code is available today at OpenStack.org. The second piece is a scalable compute-provisioning engine based on the NASA Nebula cloud technology and Rackspace Cloud Servers offering called 'OpenStack Compute.' Developers can download components of OS Compute beginning today at OpenStack.org. The first release is expected to be available later this year."

Comments (1 posted)

PacketFence 1.9.0 released

PacketFence is a GPL-licensed network access control system, useful for the imposition of all kinds of network use policies. Version 1.9.0 has been announced; the most significant changes appear to be 64-bit Linux support, node category support, and support for "floating network devices."

Full Story (comments: none)

Transifex v0.9 "Mojo" released

Version v0.9 of the Transifex translation platform is available. There's a lot of new stuff in this release, including a new extension engine, a "team sharing" feature useful for large umbrella projects, "project widgets" for the embedding of translation statistics in other web sites, and more.

Full Story (comments: none)

Newsletters and articles

Development newsletters from the last week

• Caml Weekly News (July 20)
• OpenOffice.org Newsletter (July)
• PostgreSQL Weekly News (July 18)
• Tcl-URL! (July 19)

Comments (none posted)

Dirk Hohndel at Akademy (KDE.News)

KDE.News sat down for an interview with Dirk Hohndel, Intel's chief Linux and open source technologist, at Akademy. Hohndel talked about various things including Aaron Seigo's keynote, happiness at work, and his relationship to KDE. "Dirk H: I know a lot of the early KDE community members like Kalle and Matthias. I used KDE software from the start to the 2.0 release, and lost contact for a while. I'm interested in the Linux client so since a couple of years I'm trying to figure out where it is going. I follow both Gnome and KDE development, see what is going on in the open source world. I've been repeatedly trying the latest KDE Plasma Desktop (which still fails for me for a number of reasons). The KDE community interestingly has undergone a lot of changes - very much unlike the Linux kernel where the 'oldtimers' are still very much involved. Seriously, of the 20 initial Linux developers, 15 are still very active."

Comments (45 posted)

KDE's flagship conference Akademy Concludes

KDE e.V., the non-profit organization behind the KDE desktop environment, has put out a press release about the just-completed Akademy conference. The release is subtitled "Pushing for Elegance and the Mobile Space" and features an overview of the conference that was held in Tampere, Finland June 3-10. "Using KDE software on mobile devices was another big subject of discussion and coding. The KDE community is very interested in providing their software for mobile platforms such as MeeGo. During this Akademy, work continued on making Akonadi (and in extension the Kontact Groupware Suite) and the Plasma user interface library available on MeeGo. Like the KDE community, MeeGo aims to support a full spectrum of devices in terms of formfactor and performance. Kontact Mobile provides the most scalable and powerful groupware client currently available for mobile devices, while the Plasma universal canvas provides the most mature high-level, extensible and brandable toolkit for mobile devices that are using Qt. During Akademy, the first phone call using prototype Plasma mobile phone shell was made."

Comments (9 posted)

Page editor: Jonathan Corbet

Announcements

Non-Commercial announcements

Women in free software: Recommendations from the Women's Caucus

Last September, the Free Software Foundation held a mini-summit to investigate ways to increase the participation by women in the free software community. Four separate "findings and recommendations" from the Women's Caucus that was formed at the summit have been published today. "Not enough young women are being exposed to free software. Middle school and high school are when girls potentially have the time and interest to tinker and try new things, but all too often access to public computers means running proprietary software. The Caucus is working on a plan to get free software into girls' hands, teach them how to use it and how to get the most out of free software." Click below for the full announcement.

Full Story (comments: none)

FSFE Welcomes New 'Software Interactions' Document From The European, Legal Network

The Free Software Foundation Europe has announced the release of a new educational document on Free Software licensing. "Developed by delegates of the European Legal Network, the document helps software developers and lawyers by making it easier to decide under which licenses they can distribute their work."

Full Story (comments: 8)

Articles of interest

Mozilla Would Like to Pick Your Brain - Revising the MPL (Groklaw)

Here's a Groklaw article on the update to the Mozilla Public License and license updates in general. "What I'm trying to express is simply this: it's time to seriously focus on license drafting. The purpose of lawyers is to protect your interests, to draft language that looks down the road a piece and tries to head off troubles. I think after SCO and the toy train case, we can assume there will be troubles. It would be derelict not to let the lawyers do what they do best and protect us. I know what some of you are feeling right now: sad. I feel it too. The community was built on trust, and I'm saying that now it can't be like that totally any more."

Comments (31 posted)

Kuhn: At Least Motorola Admits It

On his blog, Bradley M. Kuhn looks at Motorola's decision to lock-down its Droid X and Droid 2 phones. "I appreciate the fact that [Motorola's Lori] Fraleigh and Motorola are honest in their disdain for software developers. Unlike Apple — who tries to hide how developer-unfriendly its mobile platform is — Motorola readily admits that they seek to leave developers as helpless as possible, refusing to share the necessary tools that developers need to upgrade devices and to improve themselves, their community, and their software. Companies like Motorola and Apple both seek to squelch the healthy hacker tendency to make technology better for everyone." A related issue to ponder is the report that the Droid X will turn into an expensive brick if you try to change its firmware.

Comments (70 posted)

Neary: Rotten to the (Open) Core?

Dave Neary steps into the open core debate on his blog. Part of the problem is that people have divergent definitions of open core, he says. "There is another name for this which is even more pejorative, Crippleware. Deliberately hobbled software. And that's what I think gets people riled up — if you're releasing something as free software, then there should at least be the pretence that you are giving the community the opportunity to fend for itself — even if that is by providing an "unofficial" git tree where the community can code up GPL features competing with your commercial offering, or a nice forum for people to share templates, themes and extensions and fend for themselves. But what gets people riled is hearing a company call themselves "an Open Source company" when most of the users of their "open source" product do not have software freedom. It's disingenuous, and it is indeed brand dilution."

Comments (37 posted)

New Books

Advanced Qt Programming

"Advanced Qt Programming" by Mark Summerfield is available from Prentice Hall.

Full Story (comments: none)

Hello, Android, Third Edition--New from Pragmatic Bookshelf

The Pragmatic Bookshelf has released "Hello, Android", Introducing Google's Mobile Development Platform, third edition, by Ed Burnette.

Full Story (comments: none)

Calls for Presentations

linux.conf.au 2011 CFP opens

The Call for Papers for the 2011 edition of linux.conf.au has opened. The conference will be held January 24-29 in Brisbane, Australia. The CFP is open until August 7; more information can be found on the papers page. "The theme of this years conference is 'follow the flow'. The warm and friendly river-side Brisbane will be hosting the best linux.conf.au ever. What does the theme 'follow the flow mean'? It is about the growing movement of open source, whether its down at the kernel level or over in libre graphics."

Full Story (comments: 1)

3rd Call For Papers, 17th Annual Tcl/Tk Conference 2010

The call for papers for this year's Tcl/Tk Conference is open until August 1, 2010. The conference takes place October 11-15, 2010 in Chicago/Oakbrook Terrace, Illinois, USA.

Full Story (comments: none)

UTOSC 2010 Call for papers extended through August 1st

The call for papers for the Utah Open Source Conference has been extended until August 1, 2010. The conference takes place October 7-9, 2010 in Salt Lake City, Utah, USA.

Full Story (comments: none)

Upcoming Events

DrupalCon Copenhagen

The Drupal Association will be hosting European DrupalCon 2010 in Copenhagen, Denmark, August 23-27. Dries Buytaert, the project's founder will be giving his regular 'State of Drupal' update as one of the event's keynote presentations. More program information can be found here.

Full Story (comments: none)

FOSS4G 2010

FOSS4G 2010 will be held in Barcelona, Spain, September 6-9, 2010. Abstracts and Presentations have been posted.

Full Story (comments: none)

Events: July 29, 2010 to September 27, 2010

The following event listing is taken from the LWN.net Calendar.

Date(s)	Event	Location
July 24 July 30	Gnome Users And Developers European Conference	The Hague, The Netherlands
July 25 July 31	Debian Camp @ DebConf10	New York City, USA
July 31 August 1	PyOhio	Columbus, Ohio, USA
August 1 August 7	DebConf10	New York, NY, USA
August 4 August 6	YAPC::Europe 2010 - The Renaissance of Perl	Pisa, Italy
August 7 August 8	Debian MiniConf in India	Pune, India
August 9	Linux Security Summit 2010	Boston, MA, USA
August 9 August 10	KVM Forum 2010	Boston, MA, USA
August 10 August 12	LinuxCon	Boston, USA
August 13	Debian Day Costa Rica	Desamparados, Costa Rica
August 14	Summercamp 2010	Ottawa, Canada
August 14 August 15	Conference for Open Source Coders, Users and Promoters	Taipei, Taiwan
August 21 August 22	Free and Open Source Software Conference	St. Augustin, Germany
August 23 August 27	European DrupalCon	Copenhagen, Denmark
August 28	PyTexas 2010	Waco, TX, USA
August 31 September 1	LinuxCon Brazil 2010	São Paulo, Brazil
August 31 September 3	OOoCon 2010	Budapest, Hungary
September 6 September 9	Free and Open Source Software for Geospatial Conference	Barcelona, Spain
September 7 September 9	DjangoCon US 2010	Portland, OR, USA
September 8 September 10	CouchCamp: CouchDB summer camp	Petaluma, CA, United States
September 10 September 12	Ohio Linux Fest	Columbus, Ohio, USA
September 11	Open Tech 2010	London, UK
September 13 September 15	Open Source Singapore Pacific-Asia Conference	Sydney, Australia
September 16 September 17	Magnolia-CMS	Basel, Switzerland
September 16 September 17	3rd International Conference FOSS Sea 2010	Odessa, Ukraine
September 16 September 18	X Developers' Summit	Toulouse, France
September 17 September 18	FrOSCamp	Zürich, Switzerland
September 17 September 19	Italian Debian/Ubuntu Community Conference 2010	Perugia, Italy
September 18	Software Freedom Day 2010	Everywhere, Everywhere
September 18 September 19	WordCamp Portland	Portland, OR, USA
September 21 September 24	Linux-Kongress	Nürnberg, Germany
September 23	Open Hardware Summit	New York, NY, USA
September 24 September 25	BruCON Security Conference 2010	Brussels, Belgium
September 25 September 26	PyCon India 2010	Bangalore, India

If your event does not appear here, please tell us about it.

Page editor: Rebecca Sobol