On keys, trust, and webs

As kernel.org recovers from its compromise, there are a number of changes being made to improve security of this critical piece of kernel development infrastructure. One of the biggest changes is to remove shell access for the 450 or so developers and only allow Git pushes using SSH keys. But there is something of a chicken-and-egg problem: how do the kernel.org administrators reliably get the SSH credentials to each authorized kernel hacker, while ensuring that only that authorized user can get them? Enter GPG ...

GNU Privacy Guard (GPG) is an implementation of the OpenPGP standard (RFC4880) that provides secure encrypted communication using public key cryptography. The standard is a descendant of Phil Zimmerman's original Pretty Good Privacy (PGP) program from the early 1990s—something that put him directly at odds with the US government for a time. GPG is typically used to protect email, by encrypting it so that only the recipient can decrypt it, or by signing it in such a way that recipients can verify the message sender.

Public key cryptography (PKC) is used for most network encryption tasks, including SSH and SSL/TLS for secure web browsing (i.e. HTTPS). It requires that each user have two keys, one public and one private. The public key can (and generally should) be published widely and can be used to encrypt a message that only the holder of the corresponding private key can decrypt. The private key can be used by its owner to digitally "sign" messages (or other data) such that anyone can verify the signature by using the public key. These two modes can be combined so that an email can be sent that is only readable by its recipient who can also verify who wrote the message.

One of the main differences between OpenPGP, SSH, and SSL/TLS is in how the public keys are managed—and authenticated. SSL/TLS relies on central certificate authorities to vouch for public keys (i.e. making the connection between a public key and a domain name)—a mechanism that has suffered from serious problems of late. SSH keys are typically handled directly by the user (or administrator), by placing the public key into the authorized_keys file on the host that is to be accessed. GPG key authentication is, instead, handled in a completely decentralized fashion using a "web of trust".

The kernel.org administrators would like to be able to email credentials to and from kernel hackers securely using GPG keys. But a connection needs to be made between a given public key and a particular kernel hacker. Anyone can create a key pair claiming to belong to, say, Linus Torvalds that uses his email address; they could then present a public key that appears to be his. One could also use that key to sign Git tags, for example. How can someone distinguish Torvalds's legitimate key from any impostors? That's where the web of trust comes into play.

The web is built by people signing each other's public keys. Signing a public key serves as an assertion that the signer believes that the mapping from key to user is valid (i.e. that the name and email specified in the key is correct). So, Torvalds and Andrew Morton could get together (at the upcoming Kernel Summit for example), sign each other's key, and add those keys to their key rings (essentially a list of known keys). At that point, Morton could easily detect that the impostor's key is bogus, but other kernel hackers would not necessarily be sure, especially if the impostor also crafted a bogus key for Morton and signed both fake keys with the other.

The web of trust is what solves that particular problem. If Torvalds and Morton also sign a bunch (or even a handful) of other peoples' keys, those people can distinguish which of the keys are legitimate. If those people go on to sign additional keys, the web will grow. Anyone who can trace a path from one of their trusted keys (i.e. one that they signed), through one or more intermediates—each signed by the previous link in the chain—to the key in question, they can be reasonably assured that the key is owned by the name/email specified in it.

A chain like that described above only provides reasonable assurance because it relies on each individual being diligent about verifying the identity of people (and their keys) before signing. It also relies on people ensuring that their private keys are not compromised. Finding multiple independent paths through the web of trust, all of which agree, would greatly increase the level of trust one can place in a key as well. Shorter paths and/or more trusted signatures can also increase the trust level.

There are several levels of "trust" that one can have in a particular key. A key that you have signed is, presumably, one that you fully trust corresponds to the person that it purports to. That doesn't necessarily mean that you trust that person to be diligent about signing other keys. GPG allows trust levels to be associated with keys and has various configuration options to determine whether a given key is to be trusted for encryption purposes. By default, it requires that a key be signed by at least one person that is fully trusted or three people that are partially trusted before it will use that key.

Some projects, notably distributions like Debian, Gentoo, Fedora, and others, already have well-established webs of trust. The keys are used for package signing and other purposes, so it is important for those projects to ensure that the keys are trusted. In fact, Henrique de Moraes Holschuh suggested that geographically isolated kernel developers might find it easier to track down a nearby Debian developer to get their key signed. Most Debian developers' keys are in the "strong set" of interconnected keys in the web of trust and keys signed by strong set members automatically join that set.

In order to sign a particular public key, a user must access their private key, but, for verifying a signature, only the signer's public key is required. Basically, a cryptographic hash of the item to be signed is calculated and the hash value is what actually gets encrypted using the private key. Because of the way PKC works, the public key can be used to decrypt the hash value, which can then be compared to the hash value of the signed item. If the two match, then only the holder of the private key (which should correspond to the identity associated with the public key) could have generated the signature.

Because protecting private keys is so important, many GPG users only store those keys in a single secure location (encrypted on a secure machine or USB stick, not on their laptop). That means that the private key may not be available when someone requests a key signature. The key can still be signed, however, by collecting the key "fingerprint" (a shorter hash value that represents the key) and verifying the person's identity, then doing the actual signing later. The key to be signed can be retrieved from a keyserver and the fingerprint verified. If they match, the key can be signed and sent back to the keyserver with the new signature applied.

As part of the process for bringing kernel.org back, the administrators have put out some guidelines for generating keys and getting them signed. Several key signing parties are planned as well so that kernel hackers' keys can more quickly gather enough signatures to establish a reasonably sized web of trust. That way, the administrators can have confidence that they can send sensitive credential information to the right parties. That, in turn, will allow various kernel trees to return to the kernel.org infrastructure.

While the compromise of kernel.org is embarrassing—and worrisome—there is something of a silver lining to the incident. It will result in much tighter security, not only for kernel.org, but likely for various other pieces of critical free software infrastructure as well. With luck, it will serve as a wakeup call to many different projects and organizations who may have gotten a bit lax with their security. GPG and its web of trust will be useful tools in those efforts.

Comments (19 posted)

MeeGo becomes Tizen - maybe

Intel and the Linux Foundation (LF) jointly announced the Tizen project on September 27 in a pair of blog posts from LF Executive Director Jim Zemlin and MeeGo Technical Steering Group co-chair Imad Sousou. Tizen is a replacement for — or successor to — MeeGo in most respects, particularly because it appears (at the moment at least) that Intel will still be contributing developer resources to the project. But it also imports Linux-based technology from Samsung, which had long been a member and major contributor to the LiMo platform. Exactly what constitutes the Tizen project — technically and from a governance standpoint — is yet to be revealed. Meanwhile, a portion of the MeeGo volunteer development community is reluctant to jump in and may take MeeGo in a different direction.

Poking at the vague bits

What is immediately clear from the initial announcements is that Tizen is supplanting MeeGo as Intel's mobile Linux device initiative. Sousou's post spoke only of transitioning from MeeGo to Tizen, not co-existence. Tizen will target the same set of "vertical" device categories as MeeGo: smartphones, tablets, netbooks, smart TVs, and In-vehicle Infotainment (IVI) systems. Zemlin said that Tizen will adopt "the same principles and open source philosophies" as MeeGo, notably the "upstream first" approach to building releases primarily based on existing desktop Linux projects.

What is unclear is exactly what components Tizen will include, although Sousou said that HTML5 and JavaScript will replace Qt as the primary — if not sole — application development framework. Along those lines, MeeGo community manager Dawn Foster posted a welcome message on the new Tizen site that alluded to the fact that HTML5 does not supply device APIs for subsystems like "messaging, multimedia, camera, network, and social media", and that "for those who use native code in their applications, the Tizen SDK will include a native development kit". The SDK, however, is not scheduled to arrive until the first quarter of 2012.

An announcement on the LiMo Foundation site offers little elaboration, but does list the Wholesale Applications Community (WAC) platform alongside HTML5 as the development environment. WAC is a relatively-new coalition of handset manufacturers and mobile network operators attempting to define a standardized set of APIs for web runtimes. It currently defines APIs for accelerometers, cameras, calendar access, and contacts, and provides an Eclipse-based SDK.

Samsung itself has yet to make any formal announcement of its own at all, leading to a great deal of speculation over exactly what code the company is contributing to Tizen. Back in early September, there was public speculation that either Samsung was going to "join" MeeGo (perhaps rolling in its existing Linux-based OS Bada), or that LiMo would officially merge with MeeGo. Neither alternative seems to quite be the case. Samsung is one of LiMo's primary contributors, but LiMo is not an open source project — it defines a stack that uses the Linux kernel, but it uses proprietary components. Only LiMo Foundation member companies have access to most of the project's resources, and that does not appear to have changed as a result of the Tizen announcement.

Andrew Savory posted a detailed examination of the history of MeeGo and of Samsung's past Linux efforts. He argues that MeeGo's primary answer to the question "Why write applications for MeeGo?" was the popular and established cross-platform Qt framework. Absent a commitment to the project from Nokia, Intel looked for a substitute framework, and decided that HTML5 with JavaScript was the only framework with an established history and viable developer pool.

As for Samsung's code contributions, Savory suggests that the device maker will be donating Samsung Linux Platform (SLP), a LiMo-compliant OS that it has developed, but which has not yet been released in consumer products. What makes that possibility intriguing is that SLP uses GTK+ and the Enlightenment Foundation Libraries (EFL) as its application frameworks. Carsten "Rasterman" Haitzler from Enlightenment recently appeared on the Tizen mailing list, which suggests that EFL will be part of the "native" Tizen APIs, but he would not comment on any specifics.

Both Intel's Moblin and Nokia's Maemo used GTK+ prior to Nokia's acquisition of Qt; if Tizen does bring GTK+ back into the fold, it would be understandable that Intel and Samsung would want to downplay the yet-another-toolkit-swap angle and focus instead on the cross-platform availability of HTML5. Sousou's blog post rejects the notion that "evolving" MeeGo would have given it the platform it wanted, even by adding a robust web runtime. That suggests that the application framework for Tizen will incorporate deeper changes — but it will still likely be several months before anyone knows for sure.

The developer-on-the-street view

The lack of detail about the architecture of Tizen resulted in frustration among MeeGo community developers. The new Tizen mailing list is filled with questions about both the web runtime framework and how the underlying stack differs from MeeGo — questions that so far do not have answers. Post-announcement discussions on the MeeGo list are similar.

The LF is not shutting down the MeeGo project or infrastructure (at least for the time being), which led some MeeGo core contributors to call for continuing to develop MeeGo as an Intel-free project. That call to action seems to assume that Tizen will differ significantly from MeeGo. For his part, Dave Neary argued that it is simply too early to make such a call, and that one can only wait and see:

On the other hand, Thiago Macieira believes that the lack of information and Tizen's 2012 release date amount to asking developers to stop working for several months and wait:

Neary and Macieira's comments were directed primarily at contributors to the MeeGo core. Developers of independent applications have different concerns to consider. They clearly cannot begin substantial work on any Tizen applications before the APIs and SDK start to take shape. Just as important, though, is whether or not the new Tizen platform means throwing out all of their Qt-based MeeGo code.

Nokia's Quim Gil said that the Qt project would be happy to "provide tools for [Tizen stakeholders] to make Tizen a first class Qt platform if they wish". Several others in the same thread (including Qt developers) concurred, noting that Qt will probably "just work" on Tizen if there are not major structural changes. Perhaps more importantly, Novomok announced on September 28 that it would support Qt integration on Tizen for commercial customers.

The near-term future is less certain for device-makers that have been planning MeeGo-based products. LF's Rudolf Streif provided some insight into the impact of the move for IVI vendors, saying "MeeGo IVI's work has always been focused on the middleware on top of the Linux stack provided by MeeGo Core to support the functionality required for vehicle applications such as connectivity to vehicle networks (CAN, MOST, etc), audio management, etc. [...] In that sense all the work that has been done for IVI in conjunction with MeeGo still applies to Tizen". Intel's Joel Clark said that there will be an update to MeeGo 1.2 sometime in 2011, and that engineering support will continue for another year, but that the next major release will no longer be based on MeeGo.

Reactions

To many MeeGo community members, the status of the code and makeup of the architecture was not the main issue. They felt betrayed by the Tizen move, which seemed like a blatant reversal of the public "Intel is not blinking on MeeGo" pledge the company made after Nokia's February announcement that it would start shipping Windows 7 phones. Such a platform shift was doubly hard on veterans from the Maemo project, who had weathered Nokia's departure earlier in the year as well as a major shift in the application development framework after Nokia purchased Qt. Moreover, some felt that the strategic shift from Qt to HTML5 (regardless of Samsung's involvement) constituted a breach of the "open governance" and meritocratic principles of the MeeGo project — Florent Viard even went so far as to call it a "takeover".

In the immediate aftermath, a number of other open source projects saw the pool of unhappy developers and tried to entice them over into joining their own distribution. Jos Poortvliet was the first, beckoning MeeGo developers to come joining the OpenSUSE project (seemingly to work on OpenSUSE's ARM port). Timo Jyrinki followed, inviting the developers to join Debian instead and contribute to its smartphone sub-projects. Aaron Seigo suggested that the developers join the KDE project's Plasma Active effort, and announced a number of meetings would be held in a community IRC channel later this week.

For some, however, neither waiting for a 2012 SDK nor signing up for a different project were appealing. Carsten Munk announced the re-activation of the Mer project on October 3. Mer was initially a community rebuild of Maemo, using only open source components. After MeeGo started picking up steam, Mer was suspended, and the developers instead focused their energies on porting MeeGo builds to the not-officially-supported N900 hardware.

The revitalized Mer is described as a "truly open and inclusive integration community" for MeeGo and Tizen devices. Munk set out the goals as building an open UX layer on top of MeeGo Core, while hopefully remaining compliant with Tizen, and breaking MeeGo down into a set of flexible and modular components that are easier for device manufacturers to work with than MeeGo's large and arguably complex compliance effort. The team has already deconstructed MeeGo into 302 packages, and coaxed it into booting into a Qt UI on a Raspberry Pi board.

If Mer picks up steam (and the project members have a proven track record in recent years), there would of course be bigger challenges to be addressed, such as governance and the potential desire to move away from MeeGo conventions (such as RPM packaging). That sort of discussion has already surfaced on the MeeGo discussion lists — although it is important to observe that most of those discussions are between other community members; Munk regards reusing the RPM and Open Build System infrastructure inherited from MeeGo as a done deal.

Wherever Mer (or a community-driven MeeGo) goes in the coming months, the real challenge will be when Tizen produces its own architecture plans and governance structures. It is easy to compare "work that's available now" to vapor and prefer the former. But if Intel and Samsung deliver a compelling alternative in Tizen — especially one that proves itself more stable than the recent history of Maemo and MeeGo — then the choice becomes more muddled.

For the time being, all anyone can do about Tizen is wait for details to emerge. Foster said that Intel is deliberately taking a slower approach this time around, at least with respect to community participation and governance issues, having learned from the high-profile launch of MeeGo. Regarding the HTML5 and WAC-based application framework, information is still scarce, and, as anyone who follows "open web" news knows, there are several competing frameworks and APIs out there already — including from established open source players like Mozilla and Google Chrome. Haitzler's appearance on the Tizen list and various other tidbits about SLP make it sound like the native APIs, too, will require much explanation, but there is still no official word. Until then, the community waits.

Comments (34 posted)

Sydney Padua and "The Thrilling Adventures of Lovelace and Babbage"

If you believe Sydney Padua, then nothing to do with her web comic is due to her. "Everything I've ever done is because someone has said to me, 'Hey, you should do this,'" she says. "I need very strong pressure to do anything at all. Otherwise, I'd just be sitting on the couch."

However, fans of Padua's 2D Goggles: The Thrilling Adventures of Lovelace and Babbage might question this self-assessment. Set in an alternate 19th Century where Charles Babbage's difference engine was actually built and his collaborator Ada Lovelace did not die at thirty-seven, the comic has a pacing and sense of humor (to say nothing of a fondness for footnotes) utterly unlike anything else. Its intellectual entertainment makes Padua a fitting subject for Ada Lovelace Day on October 7, particularly because of the comic's origin in the celebration.

Growing up, Padua was an enthusiastic reader of comics — everything from Will Eisner's Spirit to Bill Watterson's Calvin and Hobbes and The X-Men. "Walt Kelly's 'Pogo' is a big influence, not just on my drawing, but on the tone of the comic," she says. "He did a lot of really gentle social and political satire, very funny and very gentle. And Carl Barks, who wrote 'Tales from the Duck Side' — I used to have stacks of his comics when I was a kid."

As an adult, Padua became an animator and special effects engineer, working on such films as The Iron Giant, Clash of the Titans, The Golden Compass, and the upcoming John Carter. Her work is done using Maya, running on GNU/Linux servers, with Python for scripting. "Every studio I've worked in, at least in London, runs on Linux", she notes. So far, she does not use free software at home, although she does say that "I'm personally interested in it in the way that anyone is who works on computers is."

Despite her geeky occupation, until beginning Lovelace and Babbage, Padua was only peripherally aware of the steampunk genre, or of web comics — although she did know about Kate Beaton, whose online comic Hark! A Vagrant often deals with historical subjects, including Ada Lovelace.

Origins and footnotes

Lovelace and Babbage is the product of the first Ada Lovelace Day in 2009:

At the time, Padua was hardly more aware of Lovelace than she was of steampunk or web comics. "It was like, 'Oh, Ada Lovelace, something to do with computers'."

Still, Padua quickly warmed to the idea. "I'd always done comics for fun, and here was one with a purpose. I started as a traditional hand-drawn animator, so it's kind of a treat for me to draw these days." As for her main characters, Padua adds, "Babbage and Lovelace were eccentric even by Victorian standards. They were off the wall — and I really respect that, actually."

Figuring that Lovelace was less than a household word, Padua began the episode called "The Origin" with a summary of Lovelace's life, followed by a humorous version of her first meeting with Babbage, which bystanders describe as "the invention of the geek". Her account of the meeting ends with Lovelace rushing off to tweet about the encounter, only to discover that she is a couple of centuries too early.

"But the ending is so miserable — she just dies," Padua says. Consequently, Padua couldn't resist going on to describe what should have happened: Babbage and Lovelace succeed in building the world's first computer, and go on to have adventures and fight crime (or at least their eccentric conception of it). "I did a drawing of them with ray guns because it was fun to draw, and used it as the end of the comic."

The comic was released under a Creative Commons Attribution Noncommercial License, and, so far as Padua was concerned, that was that. The ending was simply a good joke, and the comic "a one-off thing." However, to her surprise, "a lot of people saw it and thought that I was actually going to do a comic, which I had no intention of doing. But then I started thinking, 'What if I actually did the comic?' I started fooling around, and I guess I'm still fooling around with it."

In the second episode, "The Organist," Padua introduced the series' third main character: Isambard Kingdom Brunel, the great 19th Century engineer, whom many female readers view as the comic's beefcake. Padua herself jokes that Brunel is "the Wolverine of the early Victorians", but, in more serious moods, regards him as a pragmatic man of action who counter-balances Babbage's and Lovelace's theoretical preoccupations:

A few months ago, Brunel even showed up in the comic's blog, where, asked to help, he immediately converts a toy-like model of Padua's narrative into a massive steel and girder construction while poetically urging her to aspire to greatness — and adding an extra four pages about himself to the story outline. In fact, the addition of Brunel is typical of how Padua writes. Aside from deliberate anachronisms, many of the comics' details are historically accurate, and the jokes simply exaggerations of her characters' recorded opinions. Babbage, for example, really was obsessed with the nuisance of street musicians, and Lovelace's mother actually did try to shield her from poetry by encouraging her studies in mathematics. In this sense, Lovelace and Babbage has always been as much about Padua's research notes as the actual comic.

As Padua continued to write, she soon became absorbed by the times she was writing about:

With this fascination, Padua was soon delving deeply into original source material, tweeting about her findings as she went. "Some of the documents are more entertaining than the actual comic. Plenty of times, I've thrown something into the comic just so I'd have an excuse to refer to some document", she says. Along the way, she also became something of a believer in open access, as she found many of her historical sources disappearing for one reason or the other from the web after she linked to them.

New enthusiasms

This year, the next episode of Lovelace and Babbage, which includes an appearance by novelist George Eliot, has been delayed by Padua's special effects work on John Carter. All the same, the comic continues to develop and gain new audiences — again, thanks to other people's enthusiasms.

In June 2011, Padua was asked to produce 25 limited edition prints as thank-you gifts for donors in a fund-raising campaign for The Ada Initiative, a non-profit whose goal is to increase the participation of women in free culture and technology. Valerie Aurora, co-founder of The Ada Initiative, explains:

Yet another project began when app developer Dave Addy, who had heard Padua talk, recognized her on the London Underground. "He's another one saying to me, 'Oh, wouldn't it be fun if we did this?" Padua says. With Addy's assistance, she began work on an iPad app consisting of "The Origin" and the episode entitled "The Client," which features the young Queen Victoria, the Duke of Wellington, and his famous horse Copenhagen. For the app, which is scheduled for release on Ada Lovelace Day, Padua has cleaned up the drawings, and added more notes.

The process has also turned Padua's thoughts to the long term. "The stuff I'm putting online is just me throwing things against the wall. There's no real plan. I'm trying to figure it out now." An Android version of the app seems a likely next step, and Padua is also considering print publication.

Padua is even playing with ideas about how she might write the comic full-time. But, like many people producing free content, she is still struggling to find a way to make it pay:

Meanwhile, Padua's interest in the comic shows no signs of diminishing.

No matter who or what is responsible for the comic's erratic progressions, clearly Padua has an avocation that fascinates her as much it does her readers.

Comments (4 posted)

An odd vulnerability report for LibreOffice

An October 5 press release from The Document Foundation provides a bit of information about a vulnerability that was fixed in recent versions of LibreOffice (LO). The vulnerability sounds fairly serious: "This flaw could have been used for nefarious purposes, such as installing viruses, through a specially-crafted [.doc] file." It was evidently fixed, silently, in versions 3.4.3 and 3.3.4 of LO, which were released in August. The details (such as they are) were withheld "until users have been given time to migrate to the new version", but it isn't at all clear that Linux distributions have put out fixes yet. Worse still, OpenOffice.org (OOo) is vulnerable as well, but there has been no release from that project since January.

As of this writing, only Debian has released a security update to address the problem, and that fix is only for OOo as Debian hasn't had a release that contains LO. Other distributions may have updated LO (and/or OOo), but just as bug fix releases. They may have been misled by the release notes for LO 3.4.3, which makes no mention of security fixes (nor does the release notes for 3.3.4). Even the detailed list of fixes appears to be mute about the problem.

Now that the vulnerability has been made public as CVE-2011-2713 (just a placeholder at the moment), one would guess that other distributions will be releasing updates soon as well. Even if a bug fix update did pick up the fix, it would make sense for distributions to put out a security alert so that their users will be more likely to upgrade. But it's a little puzzling how we got to this point.

The problem was found by Red Hat security researcher Huzaifa Sidhpurwala and was fixed by Caolan McNamara of Red Hat and Marc-André Laverdière of Tata Consultancy Services, according to the press release. That would seem to clearly show that some folks at Red Hat (at least) were aware of the problem. In fact, McNamara put out bug fix updates for both OOo (for F14) and LO (for F15) in September that only mention "Update for commonly reported crashes" and "Fixes for commonly reported problems". Was the fix for CVE-2011-2713 included, but just not mentioned?

Press releases are not the usual way that vulnerabilities are announced, at least in the free software world. The wording of that release certainly indicates that the project was aware of the security implications of the fix, but withheld the information in accordance with "industry best practice". Perhaps the project was waiting until distributions were able to update their LO packages (albeit silently), but that begs another question: what about OOo?

One hopes that the press release is not the first time that the OOo community is hearing about the vulnerability, but that seems to be the case. When the press release was reported to the Apache OpenOffice (AOO) development mailing list, Dennis Hamilton indicated that it might be the first notice that AOO had received. But Simon Phipps quoted an unnamed LO developer who claimed to have alerted AOO:

Evidently, an AOO representative was not added to the mailing list, though, as Hamilton pointed out:

It certainly would have been a nice gesture—in keeping with "responsible disclosure"—for the LO folks to ensure that AOO was up to speed before putting out a press release. As Hamilton put it: "I trust this is the last time that either of our projects learn about something like this in a press release."

But Hamilton also notes that the release mentions additional fixes:

It's hard to disagree with that. There is no good reason that LO and AOO can't work together on security issues, regardless of any other friction there may be between the two. It's unfortunate that the "securityteam" mailing list didn't include any AOO folks (one guesses that it does now or will soon), but there is no reason that AOO should have learned about this problem via press release.

The LO developer's message would seem to indicate that OOo is vulnerable, but it's a little too early to say for sure. It is possible that the problem only exists in Go-OO-derived builds (which is what Linux distributions typically shipped prior to LO coming on the scene). If OOo is vulnerable, it's also unclear what AOO will be able to do about it. At the moment, AOO is in a state of flux as it transitions to an Apache incubator project. There have been no releases of the AOO project and it may still be a ways off before that can happen.

For Linux users, the problem will likely sort itself out in short order. Distributions will patch LO and OOo if they haven't already and make them available to their users. For Windows and Mac OS X users of OOo, though, the picture is murkier—at least if the vulnerability exists in those versions. There aren't distribution-like entities for applications on those platforms and the AOO project is not (yet) in a position to do security releases. It might be prudent for those users to consider switching to LO, at least temporarily, until AOO sorts itself out. Being cautious about opening random .doc files is another alternative, but that's always been good advice, though it is rarely followed.

In the final analysis, the press release raises more questions than it actually answers. What was, presumably, an attempt to shed some light on a security flaw in LO instead muddied the waters considerably. One hopes that a more transparent security process will come about for LO so that all of its downstreams—as well as its AOO "sidestream"—are notified of security problems in a timely way. In fact, both LO and AOO should be thinking about proper ways to handle and announce security fixes, perhaps along the lines of what Mozilla does. It may be "industry standard" to silently fix security holes, but free software communities can, and should, do better than that.

Comments (16 posted)

Security quotes of the week

-- H. Peter Anvin

-- Valdis Kletnieks

Comments (12 posted)

drupal6-views_bulk_operations: cross-site scripting

Package(s):	drupal6-views_bulk_operations	CVE #(s):	CVE-2011-3373
Created:	October 3, 2011	Updated:	October 5, 2011
Description:	From the Red Hat bugzilla: It was found in the way Drupal Views Builk Operations (VBO) module did not escape the vocabulary help properly, when the vocabulary has had user tagging enabled and "Modify node taxonomy terms" action was used for modification of the taxonomy. A remote attacker could provide a specially-crafted URL, which once visited by unsuspecting Drupal user, disposing with the 'administer taxonomy' permission, could lead to arbitrary HTML or web script execution (cross-site scripting [XSS] attack).
Alerts:	Fedora FEDORA-2011-13235 drupal6-views_bulk_operations 2011-09-25 Fedora FEDORA-2011-13180 drupal6-views_bulk_operations 2011-09-25

Comments (none posted)

firefox: code execution

Package(s):	firefox	CVE #(s):	CVE-2011-2996
Created:	October 3, 2011	Updated:	December 1, 2011
Description:	From the Mandriva advisory: Unspecified vulnerability in the plugin API in Mozilla Firefox 3.6.x before 3.6.23 allows remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors.
Alerts:	Gentoo 201301-01 firefox 2013-01-07 openSUSE openSUSE-SU-2011:1290-1 Seamonkey 2011-12-01 SUSE SUSE-SU-2011:1256-2 mozilla-nss 2011-11-21 SUSE SUSE-SU-2011:1256-1 Mozilla Firefox 2011-11-18 SUSE SUSE-SU-2011:1096-1 Mozilla Firefox 2011-10-06 openSUSE openSUSE-SU-2011:1076-1 xulrunner 2011-09-29 openSUSE openSUSE-SU-2011:1079-1 firefox 2011-09-29 Ubuntu USN-1210-1 firefox, xulrunner-1.9.2 2011-09-28 Ubuntu USN-1213-1 thunderbird 2011-09-28 Mandriva MDVSA-2011:140 mozilla-thunderbird 2011-10-01 Mandriva MDVSA-2011:139 firefox 2011-10-01

Comments (none posted)

mozilla: multiple vulnerabilities

Package(s):	firefox, thunderbird, seamonkey	CVE #(s):	CVE-2011-2997 CVE-2011-3001 CVE-2011-3002 CVE-2011-3003 CVE-2011-3005 CVE-2011-3232 CVE-2011-3004
Created:	September 30, 2011	Updated:	December 1, 2011
Description:	From the CVE entries: Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox 6, Thunderbird before 7.0, and SeaMonkey before 2.4 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors. (CVE-2011-2997) Mozilla Firefox 4.x through 6, Thunderbird before 7.0, and SeaMonkey before 2.4 do not prevent manual add-on installation in response to the holding of the Enter key, which allows user-assisted remote attackers to bypass intended access restrictions via a crafted web site that triggers an unspecified internal error. (CVE-2011-3001) Almost Native Graphics Layer Engine (ANGLE), as used in Mozilla Firefox before 7.0 and SeaMonkey before 2.4, does not validate the return value of a GrowAtomTable function call, which allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via vectors that trigger a memory-allocation error and a resulting buffer overflow. (CVE-2011-3002) Mozilla Firefox before 7.0 and SeaMonkey before 2.4 allow remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via an unspecified WebGL test case that triggers a memory-allocation error and a resulting out-of-bounds write operation. (CVE-2011-3003) Use-after-free vulnerability in Mozilla Firefox 4.x through 6, Thunderbird before 7.0, and SeaMonkey before 2.4 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via crafted OGG headers in a .ogg file. (CVE-2011-3005) YARR, as used in Mozilla Firefox before 7.0, Thunderbird before 7.0, and SeaMonkey before 2.4, allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via crafted JavaScript. (CVE-2011-3232) The JSSubScriptLoader in Mozilla Firefox 4.x through 6 and SeaMonkey before 2.4 does not properly handle XPCNativeWrappers during calls to the loadSubScript method in an add-on, which makes it easier for remote attackers to gain privileges via a crafted web site that leverages certain unwrapping behavior. (CVE-2011-3004)
Alerts:	openSUSE openSUSE-SU-2014:1100-1 Firefox 2014-09-09 Gentoo 201301-01 firefox 2013-01-07 openSUSE openSUSE-SU-2012:0567-1 firefox, thunderbird, seamonkey, xulrunner 2012-04-27 Ubuntu USN-1254-1 thunderbird 2011-12-22 openSUSE openSUSE-SU-2011:1290-1 Seamonkey 2011-12-01 SUSE SUSE-SU-2011:1256-2 mozilla-nss 2011-11-21 SUSE SUSE-SU-2011:1256-1 Mozilla Firefox 2011-11-18 Mandriva MDVSA-2011:169 mozilla 2011-11-09 openSUSE openSUSE-SU-2011:1076-3 seamonkey 2011-10-14 Fedora FEDORA-2011-13450 thunderbird 2011-09-29 Ubuntu USN-1222-2 mozvoikko ubufox webfav 2011-10-04 openSUSE openSUSE-SU-2011:1077-1 seamonkey 2011-09-29 Ubuntu USN-1210-1 firefox, xulrunner-1.9.2 2011-09-28 openSUSE openSUSE-SU-2011:1076-2 MozillaThunderbird 2011-10-04 Mandriva MDVSA-2011:142 mozilla-thunderbird 2011-10-01 Mandriva MDVSA-2011:140 mozilla-thunderbird 2011-10-01 Mandriva MDVSA-2011:141 firefox 2011-10-01 Mandriva MDVSA-2011:139 firefox 2011-10-01 Ubuntu USN-1222-1 Firefox 2011-09-29

Comments (none posted)

mozilla: multiple vulnerabilities

Package(s):	firefox, thunderbird, seamonkey	CVE #(s):	CVE-2011-2995 CVE-2011-2999 CVE-2011-3000 CVE-2011-2372 CVE-2011-2998
Created:	September 30, 2011	Updated:	July 23, 2012
Description:	From the CVE entries: Multiple unspecified vulnerabilities in the browser engine in Mozilla Firefox before 3.6.23 and 4.x through 6, Thunderbird before 7.0, and SeaMonkey before 2.4 allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via unknown vectors. (CVE-2011-2995) Mozilla Firefox before 3.6.23 and 4.x through 5, Thunderbird before 6.0, and SeaMonkey before 2.3 do not properly handle "location" as the name of a frame, which allows remote attackers to bypass the Same Origin Policy via a crafted web site, a different vulnerability than CVE-2010-0170. malicious web content. (CVE-2011-2999) Mozilla Firefox before 3.6.23 and 4.x through 6, Thunderbird before 7.0, and SeaMonkey before 2.4 do not properly handle HTTP responses that contain multiple Location, Content-Length, or Content-Disposition headers, which makes it easier for remote attackers to conduct HTTP response splitting attacks via crafted header values. (CVE-2011-3000) Mozilla Firefox before 3.6.23 and 4.x through 6, Thunderbird before 7.0, and SeaMonkey before 2.4 do not prevent the starting of a download in response to the holding of the Enter key, which allows user-assisted remote attackers to bypass intended access restrictions via a crafted web site. (CVE-2011-2372) Integer underflow in Mozilla Firefox 3.6.x before 3.6.23 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via JavaScript code containing a large RegExp expression. (CVE-2011-2998)
Alerts:	openSUSE openSUSE-SU-2014:1100-1 Firefox 2014-09-09 Gentoo 201301-01 firefox 2013-01-07 Mageia MGASA-2012-0176 iceape 2012-07-21 openSUSE openSUSE-SU-2011:1290-1 Seamonkey 2011-12-01 SUSE SUSE-SU-2011:1256-2 mozilla-nss 2011-11-21 SUSE SUSE-SU-2011:1256-1 Mozilla Firefox 2011-11-18 openSUSE openSUSE-SU-2011:1076-3 seamonkey 2011-10-14 SUSE SUSE-SU-2011:1096-1 Mozilla Firefox 2011-10-06 Fedora FEDORA-2011-13442 thunderbird-lightning 2011-09-29 Fedora FEDORA-2011-13442 thunderbird 2011-09-29 Debian DSA-2317-1 icedove 2011-10-05 Ubuntu USN-1222-2 mozvoikko ubufox webfav 2011-10-04 CentOS CESA-2011:1341 firefox 2011-09-29 CentOS CESA-2011:1343 thunderbird 2011-09-29 Red Hat RHSA-2011:1341-01 firefox 2011-09-28 Red Hat RHSA-2011:1342-01 thunderbird 2011-09-28 Red Hat RHSA-2011:1343-01 thunderbird 2011-09-28 Red Hat RHSA-2011:1344-01 seamonkey 2011-09-28 openSUSE openSUSE-SU-2011:1076-1 xulrunner 2011-09-29 openSUSE openSUSE-SU-2011:1077-1 seamonkey 2011-09-29 openSUSE openSUSE-SU-2011:1079-1 firefox 2011-09-29 Ubuntu USN-1210-1 firefox, xulrunner-1.9.2 2011-09-28 Ubuntu USN-1213-1 thunderbird 2011-09-28 openSUSE openSUSE-SU-2011:1076-2 MozillaThunderbird 2011-10-04 Mandriva MDVSA-2011:142 mozilla-thunderbird 2011-10-01 Mandriva MDVSA-2011:140 mozilla-thunderbird 2011-10-01 Mandriva MDVSA-2011:141 firefox 2011-10-01 Mandriva MDVSA-2011:139 firefox 2011-10-01 Fedora FEDORA-2011-13467 gnome-web-photo 2011-09-29 Fedora FEDORA-2011-13467 gnome-python2-extras 2011-09-29 Fedora FEDORA-2011-13467 galeon 2011-09-29 Fedora FEDORA-2011-13467 perl-Gtk2-MozEmbed 2011-09-29 Fedora FEDORA-2011-13467 mozvoikko 2011-09-29 Fedora FEDORA-2011-13467 xulrunner 2011-09-29 Fedora FEDORA-2011-13467 firefox 2011-09-29 CentOS CESA-2011:1344 seamonkey 2011-09-29 CentOS CESA-2011:1343 thunderbird 2011-09-29 CentOS CESA-2011:1341 firefox 2011-09-29 Ubuntu USN-1222-1 Firefox 2011-09-29 Fedora FEDORA-2011-13465 perl-Gtk2-MozEmbed 2011-09-29 Fedora FEDORA-2011-13465 xulrunner 2011-09-29 Fedora FEDORA-2011-13465 mozvoikko 2011-09-29 Fedora FEDORA-2011-13465 gnome-python2-extras 2011-09-29 Fedora FEDORA-2011-13465 firefox 2011-09-29 Debian DSA-2313-1 iceweasel 2011-09-29 Debian DSA-2312-1 iceape 2011-09-29 Scientific Linux SL-seam-20110928 seamonkey 2011-09-28 Scientific Linux SL-thun-20110928 thunderbird 2011-09-28 Scientific Linux SL-thun-20110928 thunderbird 2011-09-28 Scientific Linux SL-fire-20110928 firefox 2011-09-28

Comments (none posted)

openoffice,org, libreoffice: code execution

Package(s):	openoffice.org libreoffice	CVE #(s):	CVE-2011-2713
Created:	October 5, 2011	Updated:	November 14, 2011
Description:	As was recently disclosed by the Document Foundation: "RedHat security researcher Huzaifa Sidhpurwala identified a memory corruption vulnerability in the code responsible for loading Microsoft Word documents in LibreOffice. This flaw could have been used for nefarious purposes, such as installing viruses, through a specially-crafted file." OpenOffice.org suffers from the same vulnerability.
Alerts:	Gentoo 201408-19 openoffice-bin 2014-08-31 Gentoo 201209-05 libreoffice 2012-09-24 Ubuntu USN-1496-1 openoffice.org 2012-07-02 Mandriva MDVSA-2011:172 libreoffice 2011-11-11 Fedora FEDORA-2011-14049 openoffice.org 2011-10-09 Fedora FEDORA-2011-14036 libreoffice 2011-10-09 openSUSE openSUSE-SU-2011:1143-2 libreoffice 2011-10-18 openSUSE openSUSE-SU-2011:1143-1 libreoffice 2011-10-18 Debian DSA-2315-1 openoffice.org 2011-10-05

Comments (none posted)

openssl: denial of service

Package(s):	openssl	CVE #(s):	CVE-2011-3210
Created:	October 5, 2011	Updated:	October 5, 2011
Description:	The OpenSSL ephemeral ECDH ciphersuite implementation is not thread-safe, allowing a remote attacker to force a server crash. Version 1.0.0e contains the necessary fix.
Alerts:	Ubuntu USN-1357-1 openssl 2012-02-09 openSUSE openSUSE-SU-2011:1144-1 openssl 2011-10-18 Gentoo 201110-01 openssl 2011-10-09 Mandriva MDVSA-2011:137 openssl 2011-09-28

Comments (none posted)

perl-FCGI: authentication bypass

Package(s):	perl-FCGI	CVE #(s):	CVE-2011-2766
Created:	October 3, 2011	Updated:	January 5, 2012
Description:	From the CVE entry: The FCGI (aka Fast CGI) module 0.70 through 0.73 for Perl, as used by CGI::Fast, uses environment variable values from one request during processing of a later request, which allows remote attackers to bypass authentication via crafted HTTP headers.
Alerts:	openSUSE openSUSE-SU-2012:0004-1 FastCGI 2012-01-05 Mandriva MDVSA-2012:001 fcgi 2012-01-02 Debian DSA-2327-1 libfcgi-perl 2011-10-24 Fedora FEDORA-2011-13236 perl-FCGI 2011-09-25 Fedora FEDORA-2011-13230 perl-FCGI 2011-09-25

Comments (none posted)

puppet: privilege escalation/file overwrite

Package(s):	puppet	CVE #(s):	CVE-2011-3869 CVE-2011-3870 CVE-2011-3871
Created:	October 3, 2011	Updated:	October 17, 2011
Description:	From the Ubuntu advisory: It was discovered that Puppet unsafely opened files when the k5login type is used to manage files. A local attacker could exploit this to overwrite arbitrary files which could be used to escalate privileges. (CVE-2011-3869) Ricky Zhou discovered that Puppet did not drop privileges when creating SSH authorized_keys files. A local attacker could exploit this to overwrite arbitrary files as root. (CVE-2011-3870) It was discovered that Puppet used a predictable filename when using the --edit resource. A local attacker could exploit this to edit arbitrary files or run arbitrary code as the user invoking the program, typically root. (CVE-2011-3871)
Alerts:	Gentoo 201203-03 puppet 2012-03-05 openSUSE openSUSE-SU-2011:1288-1 puppet 2011-11-29 Fedora FEDORA-2011-13633 puppet 2011-10-01 Fedora FEDORA-2011-13636 puppet 2011-10-01 Ubuntu USN-1223-2 puppet 2011-10-05 Debian DSA-2314-1 puppet 2011-10-03 Ubuntu USN-1223-1 puppet 2011-09-30

Comments (none posted)

puppet: directory traversal

Package(s):	puppet	CVE #(s):	CVE-2011-3848
Created:	October 4, 2011	Updated:	October 27, 2011
Description:	From the Debian advisory: Kristian Erik Hermansen reported that an unauthenticated directory traversal could drop any valid X.509 Certificate Signing Request at any location on disk, with the privileges of the Puppet Master application.
Alerts:	Gentoo 201203-03 puppet 2012-03-05 openSUSE openSUSE-SU-2011:1288-1 puppet 2011-11-29 openSUSE openSUSE-SU-2011:1190-1 puppet 2011-10-27 Ubuntu USN-1217-1 puppet 2011-09-29 Debian DSA-2314-1 puppet 2011-10-03

Comments (none posted)

quagga: buffer overflow and denial of service

Package(s):	quagga	CVE #(s):	CVE-2011-3323 CVE-2011-3324 CVE-2011-3325 CVE-2011-3326 CVE-2011-3327
Created:	October 5, 2011	Updated:	September 14, 2012
Description:	Quagga suffers from four denial of service vulnerabilities and one buffer overflow (CVE-2011-3323) that could presumably be exploited for the execution of arbitrary code.
Alerts:	Scientific Linux SL-quag-20120913 quagga 2012-09-13 Scientific Linux SL-quag-20120913 quagga 2012-09-13 Oracle ELSA-2012-1259 quagga 2012-09-13 Oracle ELSA-2012-1258 quagga 2012-09-13 CentOS CESA-2012:1259 quagga 2012-09-12 CentOS CESA-2012:1258 quagga 2012-09-12 Red Hat RHSA-2012:1259-01 quagga 2012-09-12 Red Hat RHSA-2012:1258-01 quagga 2012-09-12 Gentoo 201202-02 quagga 2012-02-21 SUSE SUSE-SU-2011:1316-1 quagga 2011-12-12 Ubuntu USN-1261-1 quagga 2011-11-14 SUSE SUSE-SU-2011:1171-1 quagga 2011-10-24 Fedora FEDORA-2011-13499 quagga 2011-09-29 Fedora FEDORA-2011-13504 quagga 2011-09-29 openSUSE openSUSE-SU-2011:1155-1 quagga 2011-10-18 Debian DSA-2316-1 quagga 2011-10-05 SUSE SUSE-SU-2011:1075-1 quagga 2011-09-29

Comments (none posted)

rpm: arbitrary code execution

Package(s):	rpm	CVE #(s):	CVE-2011-3378
Created:	October 4, 2011	Updated:	November 10, 2011
Description:	From the Red Hat advisory: Multiple flaws were found in the way the RPM library parsed package headers. An attacker could create a specially-crafted RPM package that, when queried or installed, would cause rpm to crash or, potentially, execute arbitrary code. (CVE-2011-3378) Note: Although an RPM package can, by design, execute arbitrary code when installed, this issue would allow a specially-crafted RPM package to execute arbitrary code before its digital signature has been verified. Package downloads from the Red Hat Network remain secure due to certificate checks performed on the secure connection.
Alerts:	Ubuntu USN-1695-1 rpm 2013-01-17 Gentoo 201206-26 rpm 2012-06-24 CentOS CESA-2011:1349 rpm 2011-11-09 SUSE SUSE-SU-2011:1140-2 popt 2011-11-03 openSUSE openSUSE-SU-2011:1203-1 rpm 2011-11-03 SUSE SUSE-SU-2011:1140-1 popt 2011-10-17 Fedora FEDORA-2011-13785 rpm 2011-10-05 Mandriva MDVSA-2011:143 rpm 2011-10-05 Scientific Linux SL-rpm-20111003 rpm 2011-10-03 CentOS CESA-2011:1349 rpm 2011-10-03 Red Hat RHSA-2011:1349-01 rpm 2011-10-03

Comments (none posted)

samba: denial of service

Package(s):	samba	CVE #(s):	CVE-2011-3585
Created:	October 5, 2011	Updated:	October 5, 2011
Description:	A vulnerability in Samba's mtab lock file handling allows a local user to create a stale lock file, causing a denial of service.
Alerts:	Ubuntu USN-1226-1 samba 2011-10-04

Comments (none posted)

wireshark: multiple vulnerabilities

Package(s):	wireshark	CVE #(s):	CVE-2011-3360 CVE-2011-3482 CVE-2011-3483 CVE-2011-3484
Created:	October 5, 2011	Updated:	January 27, 2012
Description:	Wireshark suffers from a search path vulnerability (CVE-2011-3360) that could allow a local attacker to cause the execution of a trojan-horse Lua script. There is also the usual set of dissector vulnerabilities; version 1.6.2 contains the fixes.
Alerts:	Debian DSA-2395-1 wireshark 2012-01-27 Debian DSA-2324-1 wireshark 2011-10-20 openSUSE openSUSE-SU-2011:1142-1 wireshark 2011-10-18 Gentoo 201110-02 wireshark 2011-10-09 Mandriva MDVSA-2011:138 wireshark 2011-09-28

Comments (none posted)

Kernel release status

The current development kernel is 3.1-rc9, released on October 4. The kernel repository is back in its old location on kernel.org; Linus also has started using a new signing key with this release. "On the kernel front, not a huge amount of changes. That said, by now, there had better not be - and I definitely wouldn't have minded having even fewer changes. But the fixes that are here are generally pretty small, and the diffstat really doesn't look all that scary - there really aren't *big* changes anywhere."

Stable updates: the 3.0.5 update was released on October 3 with well over 200 important fixes; it was immediately followed by 3.0.6 to fix a build problem in the Radeon driver.

Comments (2 posted)

Quotes of the week

-- Alan Cox

-- Chris Mason

-- Ted Ts'o

-- Valdis Kletnieks

Comments (6 posted)

Better kernels with GCC plugins

Last week's article on GCC plugins drew a comment from "PaXTeam" regarding the PaX project's use of plugins. It seems they have developed a set of plugins to help with the task of creating a more secure kernel. Said plugins can be hard to find; your editor located them in the grsecurity "test" patch set. There appear to be four of them, each of which tweaks the compilation process in a different way:

• Structures containing only function pointers are made const, regardless of whether they are declared that way. Of course, it turns out that this is the wrong thing to do in a number of cases, so the developers had to create a no_const attribute and use it some 180 places in their patch.

• A histogram of the distribution of sizes passed to kalloc() is generated; it's not clear (to your editor) what use is made of that information.

• Some fairly sophisticated tweaks to the generated assembly are made for AMD processors to improve the prevention of the execution of kernel data.

• Instrumentation is inserted to track kernel stack usage.

Use of plugins in this way allows significant changes to be made to the kernel without actually having to change the code:

On the other hand, plugins of this type can increase the distance between the code one sees and what is actually run in the kernel; it is easy to imagine that leading to some real developer confusion at some point. Still, says PaXTeam, "the cost/benefit ratio of the plugin approach is excellent and there's a lot more in the pipeline". It is not too hard to imagine other uses that are not necessarily tied to security.

(Amusingly, the plugins are licensed under GPLv2, meaning that they do not qualify for the GCC runtime library exemption. The kernel does not need that library, though, so all is well.)

Comments (26 posted)

Kernel.org's road to recovery

On August 31, the world was informed that kernel.org, the primary repository for kernel code in various stages of development, had been compromised - though developers with access to the site had been informed a few days prior. The site was shut down for "maintenance" when that notice went out, leaving the community without an important hosting and distribution point. Kernel development has slowed as a result; the 3.1 kernel, which would have been expected by now, remains unreleased. Kernel.org is on its way back, but it will almost certainly never be quite the same.

On October 3, a basic kernel.org returned to the net. Git hosting is back, but only for a very small number of trees: mainline, stable, and linux-next. The return of the other trees is waiting for the relevant developers to reestablish their access to the site - a process that involves developers verifying the integrity of their own systems, then generating a new PGP/GPG key, integrating it into the web of trust, and forwarding the public key to the kernel.org maintainers. This procedure could take a while; it is not clear how many developers will be able to regain their access to kernel.org before the 3.2 merge window opens.

The front-page web interface is back though, as of this writing, it is not being updated to reflect the state of the git trees. Most other kernel.org services remain down; some could stay that way for some time. It is worth remembering that kernel.org only has one full-time system administrator, a position that has been funded by the Linux Foundation since 2008. That administrator, along with a number of volunteers, is likely to be quite busy; some of the less-important services may not return anytime soon.

A full understanding of what happened is also likely to take some time. Even in the absence of a report on this intrusion, though, there are some conclusions that can be made. The first is obvious: the threat is real. There are attackers out there with time, resources, motivation, and skills. Given the potential value of either putting a back door into the kernel or adding a trojan that would run on developers' machines, we have to assume that there will be more attacks in the future. If the restored kernel.org is not run in a more secure manner, it will be compromised again in short order.

The site's administrators have already announced that shell accounts will not be returning to the systems where git trees are hosted. Prior to the breakin, there were on the order of 450 of those accounts; that is a lot of keys to the front door to have handed out. No matter how careful all those developers may be - and some are more careful than others - the chances of one of them having a compromised machine approach 100%. Keeping all those shell accounts off the system is clearly an important step toward a higher level of security.

Kernel.org has its roots in the community and was run the way kernel developers often run their machines. So, for example, kernel.org tended to run mainline -rc kernels - a good exercise in dogfooding, perhaps, but it also exposed the system to bleeding-edge bugs, and, perhaps more importantly, obscured the real cause of kernel panics experienced last August, delaying the realization that the system had been compromised. The kernel currently running on the new systems has not been announced; one assumes it is something a little better tested, better supported, and stable. (No criticism is intended by pointing this out, incidentally. Kernel.org has been run very well for a long time; the point here is that the environment has changed, so practices need to change too.)

At this point it seems clear that a single administrator for such a high-profile site is not an adequate level of staffing. Given the resources available in our community, it seems like it should be possible to increase the amount of support available to kernel.org. There are rumors that this is being worked on, but nothing has been announced.

Developers are going to have to learn to pay more attention to the security of their systems. There are scattered reports of kernel developers turning up compromised systems; in some cases, they may have been infected as the result of excessive trust in kernel.org. Certain practices will have to change; for that reason, the Fedora project's announcement of a zero-tolerance policy toward private keys on Fedora systems is welcome. Developers are on the front line here: everybody is depending on them to keep their code - and the infrastructure that distributes that code - secure.

There is an interesting question related to that: will kernel developers move back to kernel.org? These developers have had to find new homes for their git repositories during the outage; some of them are likely to decide that leaving those repositories in their new location is easier than establishing identities in the web of trust and getting back into kernel.org. Linus has said in the past that he sees the presence of a kernel.org-hosted tree in a pull request as a sign that the request is more likely to be genuine. Requiring that repositories be hosted at kernel.org seems like an unlikely step for this community, though. It is not entirely clear whether trees distributed around the net increase the security risk to the kernel, or whether putting all the eggs into the kernel.org basket would be worse.

One other conclusion would seem to jump out at this point: kernel.org got hit this time, but there are a lot of other important projects and hosting sites out there. Any of those projects is just as likely to be a target as the kernel. If we are not to have a long series of embarrassing compromises, some with seriously unfortunate consequences, we're going to have to take security more seriously everywhere. Doing so without ruining our community's openness is going to be a challenge, to say the least, but it is one we need to take on. Security is a pain, but being broken into and used to attack your users and developers is even more so.

Comments (121 posted)

Greedy hrtimer expiration

High-resolution timers (hrtimers) can be used to invoke kernel code after a precisely-specified time interval; unlike regular kernel timers, hrtimers can be reliably used with periods of microseconds or nanoseconds. Even hrtimer users can usually accept a wakeup within a specific range of times, though. To take advantage of that fact, the kernel offers "range hrtimers" with both soft (earliest) and hard (latest) deadlines. With range hrtimers, the kernel can coalesce wakeup events, minimizing the number of interrupts and reducing power usage. These are good things, so it is not surprising that the use of range timers has increased since they were introduced.

One would think that, once the hrtimer code starts running in response to a timer interrupt, it would make sense to run every timer event whose soft expiration time has passed. But that is not what current kernels do. It is an interesting exercise to look at why that is, and how a recent patch from Venkatesh Pallipadi changes that behavior.

For the sake of simplicity, let us imagine a set of timers that we'll call "A" through "G", each expiring 10µs after its predecessor. The hard expiration times are regular, but the timers have wildly differing soft expiration times; plotted on a timeline, the example timers look like this:

As can be seen here, timer "A" has a hard expiration 10µs in the future, but it could expire any time after 5µs. Timer "B" can be expired anytime from 7.5µs to 20µs in the future; the kernel can thus expire them both at 10µs and eliminate the need to schedule a timer interrupt at 20µs. Further in the future, timer "D" has a hard expiration 40µs ahead, but it is quite flexible and could, like timer "B", legitimately be expired 7.5µs from now.

If the kernel is interrupted by a hardware timer in 10µs, it might be expected to call the expiration function for timers "A", "B", and "D". In reality, though, the expiration function for "D" will not be called at that time. To understand why, consider that hrtimers, within the kernel, are stored in a red-black tree with the hard expiration time as the key. The resulting tree will look something like this:

When the timer interrupt happens, the timer code performs a depth-first traversal of this tree for as long as it finds timers whose soft expiration time has passed. In this case, it will encounter "A" and "B" but, once it hits "C", the soft expiration time is in the future and the traversal stops. The organization of the data structure is such that the code cannot find the other events whose soft expiration time has passed without searching the whole tree.

When the hrtimer code was extended to support range timers, searching for all soft-expired timers looked like it would require the addition of a second tree over the existing tree. That was deemed to be too expensive, especially since it may not actually save any wakeups. With the current code, "D" will be expired after 30µs, when "C" hits its hard expiration. Expiring "D" sooner will not eliminate the need for a wakeup at 30µs, so it didn't seem worth the effort to expire "D" sooner.

Venkatesh thought this through and decided that he could come up with a couple of exceptions to that reasoning. It may well be that, at 10µs, the system will be less heavily loaded than at 30µs; in that case, it makes sense to get more work done sooner. Running the timer sooner also could save a wakeup if "C" is deleted prior to expiration. So he wrote up a patch to implement a "greedy hrtimer walk" that would run all soft-expired hrtimers on a timer interrupt.

He was helped by the addition of augmented red-black trees (also done by Venkatesh) in 2010. Essentially, an augmented tree allows the addition of a bit of extra metadata to each node; when a change is made to the tree, that extra information can be percolated upward. The greedy hrtimer walk patch turns the hrtimer tree into an augmented red-black tree; each node then stores the earliest soft expiration time to be found at that level of the tree or below. With the timer example given above, the new tree would look like this:

The new numbers in red tell the tree-traversal logic what the soonest soft-expiration time is in each subtree. Using those numbers, a search of the tree 10µs in the future could prune the search at "F", since all soft expiration times will be known to be at least 25µs further in the future at that time. That takes away much of the cost of searching the tree for soft-expired timers that are not on the left side.

One might still wonder if that extra work is worthwhile on the off-chance that running timer events sooner will be advantageous. After all, in the absence of specific knowledge or a crystal ball, it is just as likely that the system will be less loaded at the later expiration time; in that case, expiring the timer sooner would make things worse. Venkatesh's patch avoids that issue by only performing the greedy hrtimer walk if the CPU is idle when the timer interrupt happens. If work is being done, soft-expired timers that are not immediately accessible are left in the tree, but, if the CPU has nothing better to do, it performs the full search.

Venkatesh benchmarked this work by looking at the number of times the scheduler migrated tasks between CPUs on a given workload. Migrations are a sign of contention for the processor; they can also be expensive since processes can leave their memory cache behind when they move. Given the right workload (80% busy with a number of threads), the number of migrations was cut to just over half its previous value; other workloads gave less impressive results, but the patch never seemed to hurt. Given that, the comments on the patch were mostly focused on the details - like whether the greedy behavior should be controlled by a sysctl knob or not. Chances are this feature will show up in the 3.2 kernel.

Comments (2 posted)

Idle and stale page tracking

Google's requirements for systems running in its cluster have been discussed in public a number of times at this point; the recent Linux Plumbers Conference session on control groups is an example. The company does everything it can to pack as much work onto each system as possible to ensure that its hardware is fully utilized. One aspect of this packing is the need to make the best use possible of system memory. Michel Lespinasse's recently posted idle page tracking patch set is one piece of Google's solution to this problem.

The "fake NUMA" mechanism is currently used to control memory use within a single system, but Google is trying to move to the control-group memory controller instead. The memory controller can put limits on how much memory each group of processes can use, but it is unable to automatically vary those limits in response to the actual need shown by those groups. So some control groups may have a lot of idle memory sitting around while others are starved. Google would like to get a better handle on how much memory each group actually needs so that the limits can be adjusted on the fly - responding to changes in load - and more jobs can be crammed onto each box.

Determining a process's true memory needs can be hard, but one fairly clear clue is the existence of pages in the process's working set that have not been touched in some time. If there are a lot of idle pages around, it is probably safe to say that the process is not starved for memory; this idea is based, of course, on the notion that the kernel's page replacement algorithm is working reasonably well. It follows that, if you would like to know how memory usage limits can be tweaked to optimize the use of memory, it makes sense to track the number of idle pages in each control group. The kernel does not currently provide that information - a gap that Michel's patch set tries to fill.

The memory management code has a function (page_referenced() and a number of variants) that can be used to determine whether a given page has been referenced since the last time it was checked. It is used in a number of memory management decisions, such as the quick aging of pagecache pages that are only referenced once. Michel's patch makes use of this mechanism to find idle pages, but this use has some slightly different needs: Michel needs to know more about the pages in question, and he needs to not interfere with other users of page_referenced(). To meet these needs, Michel has to make some changes to the core memory management code.

For the first problem, the page_referenced() interface is changed to take a new structure (struct page_referenced_info) where the additional information can be recorded. Avoiding interference with existing users of page_referenced(), instead, requires adding a couple of new page flags. Since page flags are in short supply on 32-bit architectures, using more of them is strongly discouraged. This patch set gets around that problem by disabling the feature altogether on 32-bit machines; anybody wanting idle page tracking will need to run in 64-bit mode.

Systems where idle page tracking is in use will have a new kernel thread running under the name kstaled. Its job is to scan through all of memory (once every two minutes by default) and count the number of pages that have not been referenced since the previous scan. Such pages are deemed to be idle; each one is traced back to its owning control group and that group's statistics are adjusted. The patch adds a new "page age" data structure - an array containing one byte for every page in the system - to track how long each page has been idle, up to 255 scan cycles. The results are boiled down to counters showing how many pages have been idle for 1, 2, 5, 15, 30, 60, 120, and 240 cycles. Idle pages are further broken down into a few categories: clean, dirty and file-backed, and dirty anonymous pages. These counters, which are only updated at the end of each scan, can be found in the memory controller's control directory for each group.

Since the statistics are only updated at the end of each scan, and since the scans are two minutes apart, the resulting numbers are likely to lag reality by some time. Imagine that a given page is scanned toward the beginning of a cycle and seen to be in use; clearly it will not be counted as idle. If it is referenced one last time just after the scan, it will still appear to be in use at the next scan, nearly two minutes later, when the "referenced" bit will be reset. It is only after another two minutes that kstaled will decide that the page is unused - nearly four minutes after its last reference. That is not necessarily a problem; a decision to shrink a group of processes because they are not using all of their memory probably should not be made in haste.

There are times when more current information is useful, though. In particular, Google's management code would like to know when a group of processes suddenly start making heavier use of their memory so that their limits can be expanded before they begin to thrash. To handle this case, the patch introduces the notion of "stale" pages: a page is stale if it is clean and if it has been idle for more than a given (administrator-defined) number of scan cycles. The presence of stale pages indicates that a control group is not under serious memory pressure. If that control group's memory needs suddenly increase, though, the kernel will start reclaiming those stale pages. So a sudden drop in the number of stale pages is a good indication that something has changed.

When kstaled determines that a given page is stale, one of the new page flags (PG_stale) will be used to mark it. Tests have been sprinkled throughout the memory management code to notice when a stale page is dirtied, referenced, locked, or reclaimed; when that happens, the owning control group's count of stale pages will be decremented on the spot. Stale pages are not detected any more quickly than idle pages, but a reduction in the number of stale pages can be noticed immediately. That provides an early-warning system that can flag control groups whose memory use is on the increase.

The patch has been through a couple of iterations; there have been comments pointing out things to fix but no fundamental opposition to the idea. That said, memory management patches are not known for their speed getting into the mainline; if and when we'll see this feature in mainline kernels remains to be seen.

Comments (3 posted)

GeeXboX 2.0 for low-power set-top Linux

There is no such thing as a "typical media center" any more than there is a "typical computer" or a "typical user." What people expect out of a set-top box — particularly one they have built themselves — varies wildly. Some users are primarily gamers, some are DVD and Blu-Ray nuts; some obsessed with high-end audio output and some with tacking on as many video capture cards as humanly possible. You can't please everyone. The GeeXboX project just released version 2.0 of its XBMC-based set-top distribution, and it seems to have settled on a target form factor: small, low-power devices with minimal storage. The decision has its advantages, but it may limit the distribution's audience.

UnboXing

If the name GeeXboX does not ring a bell, that could be because it has been more than two full years since the project made its last release — a lifetime in "chip years." The team went through several shifts in strategic direction in the intervening time, not the least of which was the decision to write a custom media center front end (named "Enna") and then later to drop it in favor of XBMC, which is rapidly becoming the de facto front-end of choice for set-top box distributions. XBMC is a natural fit, because GeeXboX originated as a distribution for Microsoft Xbox hardware (hence the name, though the jury is still out on the justification for the capitalization).

In the same time frame, GeeXboX also spawned a number of side-projects that have fared better than Enna. The most notable is OpenBricks, an embedded Linux framework designed for building custom distributions on a variety of hardware platforms. GeeXboX 2.0 is built on OpenBricks, and indeed supports 32-bit and 64-bit Intel processors as well as ARM chips — specifically targeting the OMAP 4-based PandaBoard and the NVIDIA Tegra2. OpenGL and OpenGL ES graphics are supported for most of the platforms (a complete matrix is available on the site), and hardware accelerated video playback is supported using VA-API, VDPAU, or Broadcom CrystalHD, with Mesa as a fallback for other hardware (e.g., ATI video cards).

OpenBricks is an interesting development framework in its own right, even though GeeXboX only uses a subset of it, because it provides only the minimal environment required for running XBMC and its helper applications. Some of the other GeeXboX side-projects also live on, including libnfo (a parser for the XML-based NFO metadata format popularized by XBMC), libvalhalla (a SQLite-backed metadata scanner that fetches images and scrapes information from an assortment of web sites like IMDB), and libplayer (a high-level video playback abstraction layer providing a unified API for Mplayer, Xine, VLC, and GStreamer).

The GeeXboX 2.0 release is available as an ISO image — a lithe 72MB in size — which can run from either CD/DVD or flash-based media, with persistent storage available when using flash. The distribution boots rapidly, directly into XBMC if left unattended, although a two-second GRUB 2 menu is available to boot into single-user mode for maintenance when necessary. The XBMC build shipped is the newest, version 10.1, and although GeeXboX does not pre-load many of the skins or media-specific extensions available, it provides optical disc support and automatic discovery of SMB, NFS, HTTP, FTP, ZeroConf, and UPnP shares on the local network. A healthy selection of plug-ins are installable through the interface, although they focus mostly on web video and on metadata (such as show information) meant to supplement a media library.

Maintaining a low profile

The focus on network-delivered video reveals the direction that GeeXboX appears to be heading, even though it is not explicitly addressed in the release notes. What the project has in mind as the primary use case for GeeXboX is a small, low-power set-top box — namely, one that can hardware accelerate video playback in exchange for having a slower CPU, and probably without a hard disk for local storage.

For example, with 2.0 it is no longer possible to install GeeXboX directly to a hard disk — the "preferred" option is to run it in live USB mode with persistent storage for customizations and installed plug-ins. There is certainly nothing wrong with running a live USB front-end, but by tailoring the distribution only for that usage, the user is forced into other decisions.

It is assumed, for instance, that another system will be present on the network to serve as the main repository for audio and video content (using one of the network sharing protocols mentioned earlier). Even if a USB hard disk is attached to the set-top front-end box to make files locally accessible, such embedded devices typically do not have the CPU power to transcode video (or perhaps even audio). So a low-power front-end necessitates a second desktop or server machine somewhere, whether the content comes through Bittorrent, optical disc rips, or any other source.

The same goes for DVR functionality; previous versions of GeeXboX used the Freevo DVR application, which was later dropped in favor of Enna. But 2.0 also deprecates support for video capture cards. It is possible to use XBMC as the front-end interface to MythTV (the most common open source DVR) with a plug-in, but with GeeXboX 2.0 the MythTV back-end process will have to run on a separate machine.

This adds quite a bit of complexity — MythTV is simplest to manage when run on a combined front-and-back-end — and despite the popularity of online video delivery, the majority of video is still sent over cable, broadcast, or satellite downlinks requiring a DVR to schedule and record to disk. I am not sure exactly what approach the retro-gaming crowd takes, but GeeXboX does support several console emulator plug-ins for XBMC. Presumably flash storage is not the preferred option for retaining a library of video game ROMs, and again it is assumed that other PCs will be on the network.

Within those restrictions, there is also the issue of package updates to consider. The XBMC core is not updated frequently, although user-installed plug-ins can be updated manually through the GUI. But it appears as though subsequent ISO releases are the only update mechanism available to users, even for bug-fixes. Several users reported on the forum that their LIRC-based remote controls did not function with 2.0, and were told to "wait for [the] next release" as the only recourse.

GeeXboX uses the opkg package manager, so if the project were to start providing individual package updates installing them locally would not be difficult. However, there is no real security model in place suitable for volatile media. GeeXboX runs with one user, root, with an easily-guessable password — nay, extremely-guessable — and runs a Telnet service by default. That is not critical for anyone running from a live DVD, but considering that DVD playback is one of the key features, live USB users are more probable.

The emphasis on slim devices as video playback front-ends may be a good one from a numbers perspective; most of the media-center distributions put their effort into supporting MythTV, which is a sizable undertaking, and "over-the-top" Internet-delivered video is drastically on the rise. But it is still kind of a shame to see options disappear for users. The 2.0 announcement notes that the "GeeXboX philosophy remains the same and we still aim at targeting the most PCs and devices as possible, in an as lightweight as possible way". In practice that is a little bit misleading, because what GeeXboX really expects is that users will use a separate machine to download, record, transcode, and store the media that they watch and listen to on the lightweight playback device. But the announcement does point out the low-end device target as well: "These devices just make the perfect fanless, energy-efficient HTPC [Home Theater PC] and GeeXboX just [makes] the perfect MediaCenter distribution for those."

Instant replay

Aside from the configuration assumptions and LIRC issues, GeeXboX 2.0 is a solid effort. It boots remarkably fast, and if the reports on the forums and mailing lists are anything to go by, the hardware video acceleration is robust on the lion's share of the GPU hardware typical users will choose for their own homes. Prices have dropped enough in recent years that a fully-accelerated VDPAU-capable card from NVIDIA can be had for under US $40, and the Intel GPU support for VA-API covers most of the other common set-top options.

The LIRC trouble is disconcerting, particularly because most set-top-style cases come bundled with IR receivers and remote controls over which the buyer has very little choice. But it is a pleasant surprise to see that 2.0 supports the Boxee Box remote from D-Link, an RF device with a small footprint and a full (in key-count, not in size) QWERTY keyboard.

XBMC itself has come a long way in recent releases, straightening out unnecessary complexity and confusing navigation quirks in the UI. The main competition for a distribution like GeeXboX is the fact that you can run XBMC on a desktop Linux machine with little to no effort. That said, when you visit the XBMC downloads page, you will not find any ARM builds, and you will have to worry about hardware acceleration and HDMI output on your own.

If you are prepared to build your own lower-power box to sit on top of the television, and manage your media collection from somewhere else, then GeeXboX 2.0 may be just what you are looking for. But if you want to run a self-contained media server or DVR, it is not. However, where the project goes next may surprise everyone. This release is the first salvo fired by the new "project renewal" effort launched in July. The possibility of package updates could make the project more useful for hard disk users, and some of the side-projects (such as libplayer) are interesting enough that they could attract a following of their own.

Lastly, as lightweight as version 2.0 is, the project still apologizes for its heft in comparison to the early, 3MB releases. Employing that level of fastidious byte-counting, there is still a lot of room for new functionality before the distribution has to start worrying about bloat.

Comments (4 posted)

Distribution quote of the week

-- Josh Boyer

Comments (1 posted)

openSUSE 12.1 Beta

The openSUSE project has announced the beta of openSUSE 12.1. "If you've been following us, you know this release was originally called Milestone 6. However, the release team and its testers agreed this round of testing showed Milestone 6 to be so stable and ready for general testing, they decided to call it Beta. And that means that if you've been thinking about taking a pre-release of 12.1 for a spin before our final release in November, there's no time like the present."

Comments (1 posted)

The return of the Mer project

Some developers in the MeeGo community have decided to try to carry the code base forward as an independent, open project. To that end, they have announced the rebirth of the Mer project; they are looking for collaborators. "Some history - many of us in MeeGo originated from a project called Mer, short for Maemo Reconstructed - where we approached doing a open mobile platform through reconstruction of the Maemo platform into a open platform. We were big on open governance, open development and open source. For a few months a group of us have been working on various scenarios of change in MeeGo and now that the Tizen news is out in the open, it's time to talk about what we as a community can make happen next."

Full Story (comments: 18)

IPFire 2.11 available on ARM

IPFire is a server/firewall distribution focusing on flexibility and security. The project has announced the availability of a beta for IPFire 2.11 on ARM architecture.

Full Story (comments: none)

Announcing the release of Fedora 16 Beta

The Fedora project has announced the release of the Fedora 16 Beta. "The Beta release is the last important milestone of Fedora 16. Only critical bug fixes will be pushed as updates leading to the general release of Fedora 16 in early November. We invite you to join us in making Fedora 16 a solid release by downloading, testing, and providing your valuable feedback."

Full Story (comments: none)

Fundraising for The Debian Administrator's Handbook, English edition

The Debian Administrator's Handbook has been available in French for some time. Several editions have been published, the latest edition covers Debian Squeeze (6.0). The authors, Raphaël Hertzog and Roland Mas, are working on an English translation and are raising funds to get it published. "We would really like to see the book integrated into Debian, and therefore to see it published under a license that complies with the "Debian Free Software Guidelines". But like everybody, we need to live and feed our family, and we believe that we are entitled to have a decent payment for the work that we do." Any excess funds that are collected will be used by the authors to contribute more of their time to Debian and free software in general.

Comments (none posted)

Hackweek results for openSUSE ARM

Hackweek is a SUSE tradition in which any engineer can work on any Free Software project for a week. This year's Hackweek included a team of four SUSE employees who worked with the openSUSE community on an openSUSE ARM port. "Currently, openSUSE Factory for ARM is build for armv5tel (soft floating point with thumbs) and for armv7l (hard floating point with aapcs-linux ABI). These are widely used architectures and seem to be becoming a cross-distribution standard as well. Right now, almost 2500 packages are building successfully and tests on real hardware have shown these to work. As low-level dependencies are being fixed many more packages are expected to come in over the next couple of days."

Comments (none posted)

openSUSE Board Election Committee Formed

The openSUSE project has formed an election committee. "In the coming days and weeks, this committee will act independently to implement a formal plan for the oversight and election of a new Board for the 2012 term. Currently, three board seats will be up for election. These seats are currently held by Rupert Horstkotter, Pavol Rusnak, and Bryen Yunashko (whose seat is vacated due to term limits.)"

Comments (none posted)

Shuttleworth: P is for…

Curious readers can follow along as Mark Shuttleworth figures out what to call the Ubuntu 12.04 release. "I also like punchy and perky (the Perky Penguin is a nice nostalgic option) and persistent (better than permanent, peerless or penultimate) and playful and plucky and poised. Others like prescient and peaceable and pervasive (!) and pivotal. Pukka rings a nice old-world bell, but it’s possibly pejorative. As you can see, it’s been something of a challenge to get this right." We'll not ruin the suspense by putting a spoiler here.

Comments (36 posted)

Ubuntu Technical Board 2011

The results of a recent poll of Ubuntu developers are out. The people on the Ubuntu Technical Board for 2011-2013 are Stéphane Graber, Kees Cook, Martin Pitt, Matt Zimmerman, Colin Watson, and Soren Hansen. "We had several candidates with no historic link to Canonical, which was very encouraging in terms of the diversity of engagement in the project. For the first time, I felt we had too many candidates and so I whittled down the final list of nominations - as it happens, all of the non-Canonical nominees made the shortlist, though that was not a criteria for my support. Welcome aboard, all!"

Comments (none posted)

Distribution newsletters

• DistroWatch Weekly, Issue 425 (October 3)
• Maemo Weekly News (October 3)
• openSUSE Weekly News, Issue 195 (October 1)
• Ubuntu Weekly Newsletter Issue 235 (October 2)

Comments (none posted)

Teach your router new tricks with DD-WRT (InfoWorld)

InfoWorld has posted a lengthy introduction to DD-WRT. "In the past I've bought a router, upgraded it faithfully as new revisions to the router firmware come out, then ground my teeth in disgust when I discover, 18 months to two years later, it's suddenly no longer supported. This is dismaying, given the number of security flaws that have been found in consumer-level routers, not all of which are due to user misconfiguration. The only thing worse than no protection at all is a false sense of security, so I like the idea of using something that has at least a modicum of third-party oversight." (Here's the printable version for those who don't appreciate the convenience of an article split over six pages).

Comments (17 posted)

What's next for BerliOS projects?

It's been a good run, but after more than 11 years in service BerliOS will be shutting down. Users and projects have until the end of this year to move their data off BerliOS. The good news is, there are plenty of alternatives, though the shutdown highlights the problems of moving from one forge to another. BerliOS is providing clear instructions on getting data out but migrating to another forge is an exercise left to the project or developer.

BerliOS is operated by the Fraunhofer FOKUS institute in Berlin, Germany. In June, the BerliOS project conducted a survey to see whether there was support in the community to help fund the site. According to the announcement on September 30th, there is not enough support in the community to "put the project on a sustainable financial basis". Efforts to find a partner or sponsors to help host BerliOS that would be compatible with its open source roots were also unsuccessful.

It is unclear just how much of an effort was made to keep BerliOS afloat. Surveying users, instead of simply announcing the need for support, is a non-optimal way to try to garner support. The survey published by BerliOS was not terribly well publicized, and it's likely that many users of BerliOS were unaware of the situation until it was announced that BerliOS is closing. More successful fund-raising efforts in the open source community generally consist of making the community aware of the problem and providing specific targets for fundraising.

But BerliOS may also lack enough support, even if FOKUS had been more aggressive about fundraising. BerliOS is home to some popular projects, like avidemux, SuperTux, and Fetchmail. However, it doesn't host a lot of heavy-hitting projects. The final numbers for BerliOS are impressive, but somewhat anemic if compared to larger forges. According to the announcement, BerliOS has more than 50,000 users and 4,710 projects. It sees more than 1.6 million file downloads each month. While an impressive achievement, BerliOS hasn't seen nearly as much traffic as some of the alternatives.

SourceForge lists upwards of 313,000 projects and claims nearly 3 million downloads in one day on the banner on its front page. GitHub claims more than two million repositories and more than one million users as of September 21. Naturally, that's not an apples to apples comparison. GitHub is not solely focused on open source, nor is it a free service. GitHub claims Gists (text snippets stored in a Git repository as a Pastebin type service) as repositories. But even discounting some of the numbers as fluff, it's clear there's a lot more activity going on at GitHub or SourceForge than BerliOS.

A more apt comparison might be GNU Savannah, which claims more than 53,000 users and 3,384 projects.

BerliOS has also had its share of troubles that hint that its support staff were overmatched by the challenge of maintaining an active "forge" site. Last year in January, a compromise dating back to 2005 was discovered — but never adequately investigated. Jörg Schilling, who is employed by FOKUS to work on BerliOS, said he'd seen no sign of damage from the intrusion aside from the defacement of the site. "Therefore, I don't currently don't see a reason to issue a warning." No details about the intrusion were ever supplied.

Alternatives and migration tools

When BerliOS was founded in 2000, hosting services for free software projects were not quite as abundant as they are today. SourceForge had been up since November of 1999. The GNU Project's Savannah also launched in 2000, initially based on code from SourceForge — though SourceForge's move to proprietary software caused the GNU Project to part ways.

Since then, there's been an explosion of open source software hosting repositories. There's the aforementioned GitHub, SourceForge, GNU Savannah, and Gna for non-GNU but Libre Software projects. Developers can also migrate to Gitorious, which is a favorite for projects that are looking for a free software platform that's similar to GitHub. If a project is feeling particularly adventurous, it can host its own instance using Gitorious's software which is licensed under the AGPL.

The interoperability problem

The BerliOS folks have provided a migration guide for moving everything from project Web sites to bug trackers, databases, mailing lists, and repositories out of BerliOS. Developers are then left to their own devices to migrate those resources into another hosting facility. This highlights the problem of interoperability between various forges, something that was highlighted by Olivier Berger at the Open World Forum in 2010. Berger writes that while we have the rights to fork and patch source code, forking a project is much more difficult:

We're not quite there yet. There is a ForgePlucker project that is supposed to be building tools to migrate from "data jails" in forge systems. However, it doesn't seem to have made enough progress to be widely useful. Berger says the BerliOS shutdown may be "an [opportunity] for improvement of forgeplucker, although I don't have a clue about the maturity of its BerliOS support."

Even though BerliOS is providing tools to migrate away from the project, there will be some loss when it goes dark. Of the 4,710 projects on BerliOS, not all of them are actively maintained or will be transitioned. For example, the developer of a project called SimVis4, Jörg Rädler, said "since my activities with SimuVis are already on hold, I decided not to move to another hosting platform". Rädler says he may move to GitHub, but in the meantime, unless someone else decides to move the code to another repository it may simply disappear into the ether when the plug on BerliOS is pulled for good. One semi-serious comment on Reddit is to have a project called "SourceMorgue" to host dead open source projects.

The end for BerliOS is a bit sad, but not the end of the world. It will be an inconvenience to many projects, but not insurmountable to those that have an active community. It also highlights the need for projects to have a transition plan, and backups, no matter how stable a service looks today. No doubt many of BerliOS users were shocked to hear that the service was closing shop. Luckily, in this instance, there's plenty of notice before the doors close.

Comments (7 posted)

Quotes of the week

-- Adam Jackson

-- Matthew Garrett

-- "Masklinn"

-- Nick Coghlan

Comments (4 posted)

Denemo 0.9.2

Version 0.9.2 of the Denemo music notation editor is available. This release features improved score checking capabilities, a new set of fonts, and more.

Full Story (comments: none)

FVWM 2.6.3 released

Some users have expressed their dislike for recent releases by the major desktop environment projects; others never liked the earlier releases either. For that select group, the FVWM 2.6.3 release is available. It adds some new style commands, tweaks to the "Move" command, better control over the direction in which windows are resized, and more.

Full Story (comments: none)

The FSF fixes missing source files in GDB

The Free Software Foundation has sent out two separate notices for GDB 6.0 to 6.6 and versions 6.7 to 7.3 granting permission to distribute those releases despite the fact that they do not contain the source files for "certain CPU descriptions."

Comments (none posted)

Hugin 2011.2.0 released

Hugin is a tool for the creation of panoramic images; it was reviewed here in 2009. The 2011.2.0 release is available; significant changes include a new lens calibration tool and a Python scripting/plugin interface.

Comments (none posted)

OfflineIMAP v6.4.0

OfflineIMAP is a tool for the synchronization of mail directories using the IMAP protocol. The 6.4.0 release adds per-account locking, RFC 2595 LOGINDISABLED support, more robust synchronization, non-experimental SQLite backend support, and more.

Full Story (comments: none)

Development newsletters from the last week

• Caml Weekly News (October 4)
• Comprehensive C Archive Network News (October 1)
• Perl Weekly (October 3)
• PostgreSQL Weekly News (October 2)

Comments (none posted)

Interview with Michael Monty Widenius (ODBMS Industry Watch)

The ODBMS Industry Watch site has an interview with Michael "Monty" Widenius. "I want to ensure that the MySQL developers have a good home where they can continue to develop MySQL in an open source manner. This is important as if the MySQL ecosystem would lose the original core developers there would be no way for the product to survive. This is also in hindsight proven to be important as Oracle has lost almost all of the original core developers, fortunately most of them has joined the MariaDB project."

Comments (none posted)

Berlios to shut down

The operators of the Berlios code repository have announced that it will be shutting down at the end of the year. "Unfortunately, as a research institute Fraunhofer FOKUS has only few opportunities to operate a repository like BerliOS. Such a project will only work with a follow-up financing, or with sponsors or partners taking over the repository. In the field of OSS this is a difficult undertaking. In a recent survey the community indicated some support in funds and manpower which we would like to thank you for. Unfortunately, the result is not enough to put the project on a sustainable financial basis. In addition the search for sponsors or partners was unsuccessful." Berlios has served the community well; it will be missed.

Comments (19 posted)

Nominations sought for the 14th FSF Free Software Awards

The Free Software Foundation is looking for nominations for its annual Free Software Awards. "Last year, Rob Savoye was recognized with the Award for the Advancement of Free Software for his contributions to compiler and testing tools, and his leadership of the GNU Gnash project, a fully-free replacement for Adobe Flash. Savoye joined a prestigious list of previous winners including John Gilmore, Wietse Venema, Harald Welte, Ted Ts'o, Andrew Tridgell, Theo de Raadt, Alan Cox, Larry Lessig, Guido van Rossum, Brian Paul, Miguel de Icaza and Larry Wall." Nominations are due by November 7.

Comments (none posted)

FSF re-launches Free Software Directory

The Free Software Foundation (FSF) has announced the re-launch of its Free Software Directory. "The Directory lists over 6,500 programs that are free for any computer user to download, run, and share. It was first launched nearly a decade ago, but the new version brings a host of new features designed to make it a more useful and current resource for users, developers, advocates, and researchers."

Full Story (comments: 9)

GNOME outreach program for women accepting applications

Karen Sandler writes about the GNOME outreach program for women, which has just started accepting applications for the next round of internships. "I met many of the last round of participants in the program at the Desktop Summit and even listened to a few of them give presentations about their work. I was extremely impressed. Even better, some of these women stick around in our community after their internships are over, which is especially exciting. A couple of the women I talked to said that they believe that their careers have been kickstarted by the program and they're not sure if they would have gone down that path otherwise."

Comments (none posted)

Red Hat acquires Gluster

Red Hat has announced the pending acquisition of Gluster, an open-source storage software company. "Gluster technology offers capabilities that make it well suited to Red Hat's cloud computing strategy. Red Hat is actively building cloud solutions, as demonstrated by its IaaS/CloudForms and PaaS/OpenShift announcements earlier this year. Gluster's ability to advance Red Hat's storage capabilities also offers a unique opportunity for Red Hat and its customers. We believe Gluster's technology enhances Red Hat's cloud-computing capabilities and also offers great value in standard physical and virtual computing environments." More information, with, perhaps, fewer buzzwords, can be found in Brian Stevens's weblog.

Comments (14 posted)

SciPy India 2011 Call for Presentations

SciPy India will take place December 4-7, 2011 in Mumbai, India. The paper submission deadline is November 21. "We solicit talks and accompanying papers (either formal academic or magazine-style articles) that discuss topics regarding scientific computing using Python, including applications, teaching, development and research. We welcome contributions from academia as well as industry."

Full Story (comments: none)

CFP: Business of Open Source miniconf at LCA 2012

One of the mini conferences that will take place at the January 2012 linux.conf.au is the "Business of Open Source". The call for papers deadline for this miniconf is November 6. "Topics include licensing your work, building a market, building a community, gathering market data, distribution, communications, working with open source developers, working with governments and countries, working with procurement departments, corporate governance, funding, pricing, lessons from your experience, and whatever related topics people would like to bring up. Whether you are a student working on a one-person open source project, own your own open source consulting company, or create open source strategy for a multi-billion dollar company, this miniconf hopes to bring different people together to exchange thoughts and facilitate discussion about these topics."

Full Story (comments: none)

Events: October 13, 2011 to December 12, 2011

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

Date(s)	Event	Location
October 12 October 15	LibreOffice Conference	Paris, France
October 14 October 16	MediaWiki Hackathon New Orleans	New Orleans, Louisiana, USA
October 14	Workshop Packaging BlankOn	Jakarta , Indonesia
October 15	Packaging Debian Class BlankOn	Surabaya, Indonesia
October 17 October 18	PyCon Finland 2011	Turku, Finland
October 18 October 21	PostgreSQL Conference Europe	Amsterdam, The Netherlands
October 19 October 21	13th German Perl Workshop	Frankfurt/Main, Germany
October 19 October 21	Latinoware 2011	Foz do Iguaçu, Brazil
October 20 October 22	13th Real-Time Linux Workshop	Prague, Czech Republic
October 21 October 23	PHPCon Poland 2011	Kielce, Poland
October 21	PG-Day Denver 2011	Denver, CO, USA
October 23 October 25	Kernel Summit	Prague, Czech Republic
October 24 October 28	18th Annual Tcl/Tk Conference (Tcl'2011)	Manassas, Virgina, USA
October 24 October 25	GitTogether 2011	Mountain View, CA, USA
October 24 October 25	GStreamer Conference 2011	Prague, Czech Republic
October 26 October 28	Embedded Linux Conference Europe	Prague, Czech Republic
October 26 October 28	LinuxCon Europe 2011	Prague, Czech Republic
October 28 October 30	MiniDebConf Mangalore India	Mangalore, India
October 29	buildroot + crosstool-NG Developers' Day	Prague, Czech Republic
October 31 November 4	Ubuntu Developer Summit	Orlando, FL, USA
October 31 November 4	Linux on ARM: Linaro Connect Q4.11	Orlando, FL, USA
November 1 November 3	oVirt Workshop and Initial Code Release	San Jose, CA, USA
November 1 November 8	2011 Plone Conference	San Francisco, CA, USA
November 4 November 6	Fedora Users and Developer's Conference : India 2011	Pune, India
November 4 November 6	Mozilla Festival -- Media, Freedom and the Web	London, United Kingdom
November 5 November 6	Technical Dutch Open Source Event	Eindhoven, The Netherlands
November 5 November 6	OpenFest 2011	Sofia, Bulgaria
November 7 November 11	ApacheCon NA 2011	Vancouver, Canada
November 8 November 12	Grace Hopper Celebration of Women in Computing	Portland, Oregon, USA
November 10 November 12	Clojure/conj 2011	Raleigh, NC, USA
November 11 November 13	Free Society Conference and Nordic Summit 2011	Gothenburg, Sweden
November 11 November 12	Zentyal Summit	Zaragoza , Spain
November 12	London Perl Workshop 2011	London, United-Kingdom
November 12	Emacsforum 2011	Copenhagen, Denmark
November 14 November 17	SC11	Seattle, WA, USA
November 14 November 18	Open Source Developers Conference 2011	Canberra, Australia
November 17 November 18	LinuxCon Brazil 2011	São Paulo, Brazil
November 18	LLVM Developers' Meeting	San Jose, CA, USA
November 18 November 20	Foswiki Camp and General Assembly	Geneva, Swizerland
November 19 November 20	MediaWiki India Hackathon 2011 - Mumbai	Mumbai, India
November 20 November 22	Open Source India Days 2011	Bangalore, India
November 24	verinice.XP	Berlin, Germany
November 28	Automotive Linux Summit 2011	Yokohama, Japan
December 2 December 4	Debian Hildesheim Bug Squashing Party	Hildesheim, Germany
December 2 December 4	Open Hard- and Software Workshop	Munich, Germany
December 4 December 9	LISA ’11: 25th Large Installation System Administration Conference	Boston, MA, USA
December 4 December 7	SciPy.in 2011	Mumbai, India

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