LWN.net Weekly Edition for October 6, 2011

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)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

• Security: An odd vulnerability report for LibreOffice; New vulnerabilities in Mozilla products, OpenSSL, Puppet, RPM, ...
• Kernel: Kernel.org's road to recovery; Greedy hrtimer expiration; Idle and stale page tracking.
• Distributions: GeeXboX 2.0 for low-power set-top Linux; Fedora, Mer, openSUSE, ...
• Development: What's next for BerliOS projects?; Denemo, FVWM, GDB, Hugin, ...
• Announcements: Berlios to shut down; FSF Free Software Awards; FSF Free Software Directory; GNOME outreach program; Red Hat acquires Gluster.