LWN.net Weekly Edition for October 20, 2011

Hands on with Plasma Active One

Touchscreen tablets are all the rage these days, though Linux support for them has arguably been late in coming. While Android has made a (closed) release for tablets, free software alternatives have lagged, though both GNOME and KDE are working on the problem. In fact, KDE recently announced its entrant, Plasma Active One, which is the first of three currently planned releases of its touch-based user experience. Giving the new interface a test drive would seem mandatory.

While Plasma Active One can be run in a virtual machine, that is not the recommended configuration. Instead, the installation wiki page suggests several recent tablet devices, like the WeTab or ExoPC, as test systems. I happened to have another of the suggested devices, a Lenovo Ideapad, due to the generosity of Intel at the Dublin MeeGo conference, so I gave Plasma Active a try on that.

The project provides two different live-USB images for testing Plasma Active One, one based on openSUSE 11.4 and the other based on MeeGo 1.2. Both boot directly into the interface, which, after sliding the unlock icon, lands you on a "Introduction" activity that includes a bit of documentation on how to use the interface along with a video that demonstrates many of its features (which can also be seen on the project home page). Both live images worked well, though slowly, which may be expected when running from USB. To try to see Plasma Active One running at full speed, I installed openSUSE 11.4 (as the MeeGo live image seemed unhappy with the Broadcom WiFi on the Ideapad) and followed the wiki instructions to install it. While the speed definitely improved, it was still kind of pokey (in particular, applications loaded very slowly), which may be a reflection of the hardware rather than Plasma Active One itself.

Activities

"Activities" are the central organizing principle of Plasma Active, and the demo systems come with an example activity ("Vacation Planning") as well as a blank "My First Activity" to be filled in by new users. The idea behind activities is to group selected applications, bookmarks, contacts, documents, images, and other objects into a collection that can be switched to easily as the user changes the tasks they are working on. Activities are accessed from the activity "wheel" (or "switcher", seen at right) that gets "pulled" to the left from a tab on the right-hand side of any activity screen. The wheel allows the users to "spin" through their activities to one of interest using a swipe gesture. It's a little hard to describe the action of the wheel, but the video shows it clearly early on. Users can touch any visible activity to switch to it, and activities can be created and deleted from the wheel as well.

The wheel view gives both the name and background image of the activity, which makes it fairly easy to quickly pick the one you are looking for. Switching to an activity brings up its "home screen" (an example activity is shown at left), which consists of various elements that have been connected to that activity. So there may be an "Application" window containing the programs that the user deemed important to that activity, a "Bookmark" window with relevant browser bookmarks, and so on. Various widgets can also be attached to an activity for things like notes, clocks, weather, etc.

The elements (windows, widgets) on the activity home screen can be moved around, scrolled, and resized in the obvious ways (obvious to other touch interface users anyway). There are some constraints on the sizes and positions of the elements so that they do not overlap, but the size/position is also limited to a fairly coarse grid. That makes sense for touch-oriented interfaces, but may seem a little too rigid to some. The activity screen itself is not limited in the vertical direction, though, and can be scrolled to access further real estate as needed.

Applications

Applications can be run either from an activity's list or from the launch area. Pulling down the "Peek and Launch" bar (which lives at the top of the screen and contains status icons for battery, network, and others, along with some control elements) will expose a live view of the currently running applications that can be switched to with a touch. Pulling the bar down further exposes the launch area (seen at right), which displays various applications that can be started. As might be guessed, additional running applications or launchable applications can be accessed by swiping the appropriate area to the right or left.

Applications generally run in full-screen mode, which makes sense for a tablet interface even if it still feels strange to curmudgeons like me who are used to seeing more than one application at once. There are various ways to navigate away from a running application. The first is the running-application-panel mentioned above, which can also be used to quit any running application by touching its close icon. Another method is to touch the activities icon in the far upper right corner, which returns you to the current activity's home screen (and leaves the application running in the background). It is a little difficult to get used to, but is fairly straightforward to use once you do.

There are three other icons in the upper right, corresponding to another central idea in Plasma Active: share, like, and connect (SLC). The idea is that compliant applications will be able to offer ways to share (via social media, email, etc.), like (ratings, favorites, ..), or connect (to an activity or calendar event for example) their content. So a user could connect a web site to one of their activities, share a photo with one of their friends (or many of them via a web service), rate a particular document for use in desktop searches, etc. Currently, though, few applications have added SLC functionality.

Many applications work quite well under Plasma Active One, including Firefox, LibreOffice Math, Marble, and others. While those applications are not targeted at touchscreen interfaces, it is still fairly easy to use them (though typing can be painful, see below). The Kontact Touch applications on the other hand have been written with touchscreens in mind. Things like the calendar and contacts applications were very easy to use and seemed to have all of the functionality that one is used to from, say, the equivalent Android apps.

Some glitches

A touchscreen keyboard is available for text entry, though it suffers from many of the same annoyances that other implementations do. It sometimes pops up in places that cover the text entry field—as it did for searching applications in the screen shot at left—though it can be shifted to the top or bottom of the screen using the arrow icon. It is not really suitable for anything other than entering short text. That's a limitation of the tablet form factor, but the Ideapad does have a hardware keyboard which makes things a bit easier. The on-screen keyboard does show each key value as it is pressed, but the reaction time seemed slow. It also doesn't always pop up or disappear at the right times. For someone whose normal interface to a computer is largely through the keyboard, it was irritating, but that may be partially due to the curmudgeon effect.

There were a number of other glitches that I observed with the three different versions (the two live-USB versions and the installed openSUSE version) of Plasma Active One that I tried. Some may be attributable to the hardware (CPU, graphics, touchscreen) of the Ideapad, but likely others are bugs of one sort or another. The image viewer was flaky (at least in the openSUSE versions, the MeeGo version worked fine), the updates of the running application view would sometimes get out of sync when closing applications, sometimes multiple tries were needed to activate an icon or button, the calendar has an irritating habit of popping up when trying to swipe the Peek and Launch bar (the time, which brings up the calendar, is dead center in the bar), and so on. Those kinds of problems are to be expected in a first release, and many are undoubtedly fixed in more recent development versions. Plasma Active is by no means complete—or completely working—but it is an impressive start.

What's most interesting about Plasma Active is that it has taken its own path. Rather than adopt one of the existing touchscreen interfaces, or picking and choosing the "best" parts of Android/iOS/webOS/etc., KDE has come up with its own paradigms for Plasma Active. As more folks start to use it, the interface may change down the road—something that's already been seen between some early demos at the Desktop Summit in Berlin and the current version. Free software is often accused of being imitative, and not innovative, but KDE and the Plasma Active team cannot be pinned with that label here. Whether one likes Plasma Active or not, it is certainly a bold step in an interesting direction.

Comments (8 posted)

Time zone database attacked but finds a new home

Time is relative, and local time doubly so. The average Linux user may not think about time zones other than at installation time or when on the road, both occasions when one has to pick out their current geographic location on a tiny map, so that the OS can adjust the clock to the local standard. But collectively, all of those individual clock-setting actions add up to the need for a global database — one that needs updating far more frequently than many realize. The database referenced by Linux and most other Unix-like OSes came under fire in October, but has now found a more permanent home.

Unix-like OSes internally maintain the system time as "Unix time", which is the number of seconds since midnight January 1, 1970 in Coordinated Universal Time (UTC), but omitting any leap seconds. UTC is essentially Greenwich Mean Time, and does not have the seasonal adjustments for "daylight saving time" or "summer time" used in many regions. Ensuring that all hosts agree on the time is of course critical to the success of many network protocols, but UTC is not convenient for most of the world's users. User-facing time (including filesystem timestamps, cron jobs, the panel clock, and most messaging or calendaring applications) is presented as the system time adjusted to the local clock, based on the current location.

Exactly what the correct adjustment is depends on several factors, though. The boundary lines between time zones are stable in most countries, but they do change periodically, particularly at the provincial or city level. Whether and when a location observes daylight saving time changes more frequently — often based on political and economic factors rather than any objective or scientific reason — and the addition of leap seconds happens only when the International Earth Rotation and Reference Systems Service (IERS) deems it necessary. On top of determining the current time, however, programs often need to look up the local time for past events.

The solution to this multi-faceted problem is the "tz database", which records the difference between Unix time and local time for 405 distinct regions of the globe. Every change of that delta — whether a leap second, a daylight saving time transition, or any other adjustment — is encoded as a rule. The 405 regions represent those contiguous zones where a single rule has governed the offset from UTC since January 1, 1970, although the database contains some historical records that go much further back. For years the tz database was maintained by volunteers Arthur David Olson and Paul Eggert, with the data hosted by Olson and Eggert's employer, the US National Institute of Health (NIH), along with the tz public mailing list to discuss and announce changes to the data.

Linux systems usually provide the database as the tzdata package, which stores entries in /usr/share/zoneinfo/. The zones are broken down hierarchically by geographic region in human readable form, usually named for the country or largest city in the zone, whichever would be less ambiguous. The GNU libc utilities provide a set of command-line programs to work with the tz database: tzselect, zdump, and zic.

Time out

All was well until Olson posted a startling message to the tz list on October 6 (GMT), announcing that a lawsuit had been filed against him involving the tz database — and that he was therefore shutting down the FTP server and mailing list. In the days that followed, it came out that the lawsuit in question had been filed by Astrolabe, Inc, a purveyor of commercial astrology charts, books, and software, and that Eggert was also named as a defendant (although NIH was not).

The lawsuit (which is visible online) accused Olson and Eggert of copyright violation, because Olson and Eggert gathered some of the historical time zone adjustment data from a book called the ACS Atlas. The ACS Atlas was a reference book of historical facts intended to be useful for astrologers creating or working with "birth charts". Its original publisher went bankrupt and Astrolabe purchased the publication rights to the atlas in 2008. The book does not appear to be in print anymore, but the company does sell a Windows-based application called ACS PC Atlas including the same information.

The lawsuit accuses Olson and Eggert of "unlawful reproduction" of data from the ACS Atlas and of having "wrongfully and unlawfully asserted that the information and/or date [sic] taken from the Works is in the 'public domain.'" It seeks a restraining order and a permanent injunction prohibiting both from "unlawfully publishing any and/or some part of the Works" as well as monetary damages. The lawsuit came as a shock to the tz database community, as well as the Unix community in general, in part because the suit claims that including facts from the book in the database deprives the publisher of income — when the references to the ACS Atlas in the comments actually encourage its use.

The fact zone

But the far bigger problem with the suit is that Astrolabe asserts that the facts in the book are protected by copyright. This would seem to be a matter of settled law in the United States, where the courts have repeatedly ruled that facts or information are not copyrightable material. The Copyright Office even has a FAQ entry and a circular [PDF] explaining the distinction, which lists under "What is Not Protected by Copyright"

... although, naturally, actual court decisions are what matter.

The most prominent ruling is Feist v. Rural (1991), in which the US Supreme Court decided that information was non-copyrightable, even when considerable time and effort went into collecting and compiling it in the published work. Rural Telephone Service Company, a telephone cooperative, had sued the phone book publisher Feist for copying 4,000 entries directly out of Rural's own phone book. The court ruled that originality was required for a work to be protected by copyright, but that even in the case of collections of information or facts, only the "creative aspects" of the collection were subject to copyright protection — not the underlying facts themselves.

The 2003 Assessment Technologies v. Wiredata ruling (mentioned in the "Implications" section of the Feist v. Rural Wikipedia page) extended this idea further, saying that is it "fair use" to reverse-engineer a copyrighted work to extract the underlying factual information from it. The 1987 Worth v. Selchow & Righter Company case would also seem to apply; in that case, Worth — the author of a trivia encyclopedia — sued the creators of the Trivial Pursuit board game for bulk-copying his questions and answers, including many typos. The court ruled in Trivial Pursuit's favor, that facts are not subject to copyright protection.

The Astrolabe lawsuit does not claim that the tz database reproduces any of the ACS Atlas verbatim (which it might be argued was copyrightable as "creative expression"), but the underlying data. Tz database fan and blogger Dave Braverman posted an analysis of the lawsuit on October 6, which resulted in a lengthy press-release-like comment from Astrolabe CEO Gary Christen. Christen claimed that the contents of the ACS Atlas were more than "mere compilations of fact" because the authors had used "ingenuity" researching records and reconciling inconsistencies based on their "best judgments and expertise." Braverman replied with a follow-up post dissecting Christen's comments and predicting swift failure in court.

In another wrinkle, developer Curtis Manwaring wrote to the tz list claiming that the lawsuit was in fact just one part of a larger attack aimed at him. Manwaring is the developer of a rival astrology software product, one that uses the tz database in lieu of ACS Atlas, and claimed that the Astrolabe lawsuit is intended to scare him into licensing ACS Atlas data for his own product.

News from the legal front has been quiet for the past week; several members of the community offered to contribute to a legal defense fund for Olson and Eggert, but none has yet been announced. In the meantime, however, the tz database itself quickly found a new home.

ICANN has TZ

On October 14, the Internet Corporation for Assigned Names and Numbers (ICANN) announced [PDF] that it was taking over the hosting and maintenance of the tz database. ICANN cited a request to take over administration of the database from the Internet Engineering Task Force (IETF), and quotes ICANN Chief Operating Officer Akram Atallah as saying "The Time Zone Database provides an essential service on the Internet and keeping it operational falls within ICANN's mission of maintaining a stable and dependable Internet." It does not mention the lawsuit, although ZDNet Australia quoted ICANN's Kim Davies as saying "We are aware of the lawsuit [...] We'll deal with any legal matters as they arise."

Moving the home for the tz database has been in the works for a while, for reasons completely unrelated to the recent lawsuit. Olson announced the need for a new home in August 2009 because he would "be eligible to start drawing a pension in mid-2012". Since that time, discussions have gone on about where to house the database, and ICANN was certainly in the mix, so the move there doesn't come as a complete surprise.

ICANN is best known for managing the top-level domains of the domain name system and IP address allocations, both through its subsidiary entity the Internet Assigned Numbers Authority (IANA), though it also oversees several protocol number assignments, character encodings, and URI standards. Although it works closely with the IETF, the two organizations are not legally linked.

The tz mailing list came back online — from an ICANN server — a week before, on October 7, and numerous list members posted links to mirrors of the original server's FTP contents. Long-time volunteer Robert Elz appears to be the de-facto manager of the database for the time being, but so far it still appears to waiting for an "official" home server from ICANN. Elz told the list that he has been in contact with ICANN, and that the organization has no intention of interfering with the way the project is run. However, Elz also told the list that he is not interested in taking on management of the project long-term, as he — like Olson — is approaching retirement age.

Time++

Based on the available facts, the Astrolabe lawsuit is baffling at first glance. Unless it was a desperation play by a company rapidly going out of business, it would not seem to be worth the effort. Granted, reading the tea leaves of the legal system is tricky at the best of times, but there are multiple court cases directly refuting the plaintiff's central claims — including a US Supreme Court ruling. What hope could there be to collect damages?

That is, unless Manwaring's story is the key piece of the puzzle. If the lawsuit is actually an attempt to damage a competitor by taking out his alternative source for historical time zone data, then the suit makes more sense — particularly the fact that it names the two individuals as defendants, but not NIH. Individual defendants would be more likely to simply take down the database (which they did), in theory denying Manwaring access to it. The suit references a "takedown notice" sent to Olson and Eggert on-or-around May 12 of 2011, well before the lawsuit was filed (on September 30). Manwaring's product, Terran Atlas, released version 2.0 on May 16, and the product page goes into considerable detail about the merits of the tz database over ACS Atlas.

But if shutting down the tz database (rather than collecting damages) was Astrolabe's goal, then it would appear to have backfired. The information is still available (both through FTP mirrors and through updated tzdata packages), and ICANN has far more weight to throw around than most other defendants. Pursuing a similar case against it would have easily-foreseeable results. Just as importantly, if the current lawsuit continues, the community seems poised to come to Olson and Eggert's assistance.

Comments (18 posted)

Fifteen years of KDE

Fifteen years ago, the graphical interface on GNU/Linux consisted mostly of window managers and basic environments like Motif and CDE that came from the proprietary Unix world. As one of the first GNU/Linux-targeted GUI efforts, the development of the K Desktop Environment became a catalyst for rethinking that situation. It's a role that KDE continue to play as the project celebrates its fifteenth birthday, continuing its tradition of innovation and — from time to time — controversy.

Like the Linux kernel, KDE started with an email. "Unix popularity grows thanks to the free variants, mostly Linux. But still a consistent, nice looking free desktop-environment is missing," Matthias Ettrich posted on the Usenet group de.comp.os.linux.misc on October 14, 1996. "There are several nice either free or low-priced applications available, so that Linux/X11 would almost fit everybody needs if we could offer a real GUI."

Ettrich went on to explain that existing solutions were inadequate because of the lack of a common framework and aesthetic. He suggested using Trolltech's Qt framework — then less than year old — and offered a to-do list of needed tasks, concluding:

At first, Ettrich called the project the Kool Desktop Environment, echoing CDE. However, the name quickly settled down to the K Desktop Environment (KDE), with the "K" not standing for anything. The name stood until 2009, when the project rebranded itself as simply KDE, on the grounds that it was no longer just a desktop, but a community of related software projects.

Originally, Ettrich envisioned the first version being released by Christmas 1996. However, the already ambitious project grew in scope, and with the amount of work needed, the first version was not released until 12 July 1998. The news release was concerned mostly with justifying KDE, and included KOffice as part of the announcement.

Gun-metal gray with no anti-aliasing of fonts, like most interfaces of the time, KDE 1.0 was clumsy-looking by modern standards, and not nearly as unified as Ettrich perhaps envisioned — if only because it had to accommodate many non-KDE applications. However, by the standards of the time, it was far ahead of anything else available for Unix-like systems.

The Qt controversy

With its first release out of the way, KDE settled down to a series of minor releases, moving gradually towards the 2.0 release on 23 October 2000, a re-engineering that brought KDE closer to its ideal of a modular, consistent desktop, and introduced Konqueror as its web browser and file manager — a combination that was popular at the time.

However, even before the 1.0 release, KDE was facing criticism because of its choice of the Qt framework. For KDE, using Qt was largely a matter of practicality: project members considered it the best GUI toolkit available, it was free of charge, and it might encourage commercial software developers to work with KDE.

From the start, Qt was available under different terms for commercial and community purposes. Unfortunately, Qt's first community license, the FreeQT License, was considered non-free by the Free Software Foundation and contrary to the Debian Free Software Guidelines, which was then the second major arbiter of software license's freedom. Moreover Trolltech took several efforts to produce a new license that was generally recognized as free.

At any rate, the second license for non-commercial use, the Q Public License, made little difference. It required that all changes to Qt be made available as a patch so that the code base would remain the same for both free and commercial Qt versions. Since this requirement would mix free and proprietary software, the Q Public License was no more acceptable to the larger community than the FreeQT License was.

In response to this dispute, Trolltech and KDE announced the FreeQt Foundation, whose members signed an agreement that a free version of Qt would always be available. Trolltech and its successors were also obliged to produce a new release at least once a year. If it failed to do so, the latest free version would be released under a BSD-style license. The intricacy of the solution failed to satisfy critics, and the GNU project created the Harmony Project (not to be confused with several projects that have used that name, including the recent copyright assignment project founded by Canonical), whose goal was to create a free Qt clone.

Meanwhile, the dispute was continually escalating into a flame war, fanned by the dedicated beliefs of free software advocates and Trolltech's apparent reluctance to move towards a truly free license. In the Debian project, KDE was a main reason for a general resolution to eliminate all non-free software (it failed). The Free Software Foundation responded just as strongly with the creation of the GNOME project to create a desktop that was unequivocally free.

The dispute was abruptly resolved when Trolltech announced in September 2000 that, after consultation with critics, it now considered the GNU General Public License (GPL) a widespread standard, and would use it for Qt's next release. When the third version of the GPL was eventually released, Qt subsequently moved to it without any real controversy. Since the Nokia acquisition of Trolltech, Qt has switched to the GNU Lesser General Public License (LGPL).

But old feuds die hard, and the animosity between GNOME and KDE still occasionally flares to this day, even though the main reason for it no longer applies. The only difference is that, in recent years, arguments usually center on GUI toolkits and design choices instead of licenses.

The "Golden Age" and beyond

No longer concerned with licensing issues, KDE released a series of uneventful minor versions, before making a major break with the past with KDE 3.0 on 3 April 2002. The release featured improved display capabilities and increased customization and internationalization. Even more importantly, it created subsystems of specialized libraries, including ones for printing, personal information, and document and network protocol access that any KDE-compliant application could easily access. More than any previous release, KDE 3.0 fulfilled the original intention of a fully modular environment.

Some developers criticized the massive rewriting of KDE, and some users described the default icons as childish and unbusinesslike. However, for many, KDE 3.0 was the release showed that GNU/Linux was finally near to equaling proprietary desktops. It became a classic desktop, surviving six years with only incremental releases — three times as long as the previous major releases.

However, gradually the KDE 3 series began showing its age, and rewriting became easier than patching. After two years of planning and development, KDE released KDE 4.0 on 11 January 2008. KDE 4.0 went even further than the KDE 3 series in producing modular subsystems for everything from multimedia (Phonon) to personal information (Akonadi) and interfaces (Plasma). It also added a MySQL database for Akonadi's storage of information.

Even more importantly, KDE 4.0 expanded the concept of the desktop by emphasizing virtual workspaces, easily swappable icons and desktop layouts, desktop widgets, hot spots on the screen edges, and an array of other innovations. For the first time, a free desktop could plausibly be argued to have not only caught up with its proprietary rivals, but leaped ahead of them as well.

"Personally, I naively thought that we had really proven ourselves with KDE 3," Aaron Seigo told me five months after the release. "We had taken the promise of KDE 2 and matured it to KDE 3.5.9. And then we were going to attempt to replicate the results of that previous effort and take it to a whole new level."

But that wasn't how the release turned out. Despite all the promise, the release was something of a failure, provoking hundreds of hostile responses. KDE had failed to emphasize sufficiently that KDE 4.0 was a developer's release, and distributions — eager to offer the latest software — ignored the fact. Users were faced with a desktop that lacked many of the customization features of the KDE 3 series and introduced a sometimes bewildering set of innovations. Jokes, such as Seigo's remark that he had just removed desktop icon support in 4.1 (because icons were now part of the Plasma, and no longer confined to a single desktop) only increased the hostility and the confusion.

Three years later, some users still insist that the third release series was the height of KDE development, and that the fourth series continues to lack features found in the third. Still others consider KDE 4.0 as an example of how developers are divorced from the needs of end-users. However, as minor releases have gradually improved the user experience, most users seem to recognize the KDE 4 series as the accomplishment that it is.

Into the future

As KDE celebrates its fifteenth anniversary, KDE 5.0 seems some distance away. Although the KDE 4 series will be four years old in January 2012, it remains flexible enough that its possibilities are not yet exhausted. For example, the abstraction of the interface from the core code into the Plasma subsystem has allowed Plasma Netbook to be offered as an alternative interface on any KDE installation. The just-released Plasma Active One also shows this flexibility as an interface for touchscreen tablets.

In fact, you might say that with the KDE 4.0 series, KDE is at last fulfilling the vision of fifteen years earlier of a modular, easy to use desktop. Adjusting to circumstances and controversies, KDE has weathered four major releases, and looks ready for another fifteen years of equal accomplishment.

[Note: KDE has no shortage of histories online. For example, the KDE History Page lists conferences and a timeline of events and releases, while The Qt Issue and The History of KDE on the UserBase Wiki gives KDE's side of the controversy over the development framework. A screen shot history is available on Saeid Zebardast's blog and from the screen shot page on the main KDE site (which is where the screen shots for this article were obtained). Those interested in KDE 4.0 might look for my "What Went Wrong with the KDE 4 Release?" when the Linux.com archives are restored.]

Comments (78 posted)

Page editor: Jonathan Corbet

Security

Convergence: User-controlled SSL certificate checking

SSL certificate authorities (CAs) have been in the news quite a bit in the past year or so, and not in a good light. Back in 2008, researchers at Carnegie-Mellon University published a paper outlining a different approach that they termed Perspectives, in which a user would query multiple independent "notaries" about the authenticity of an SSL certificate, rather than relying on a centralized CA. Convergence is a new project that builds on the ideas established in the Perspectives system, ideally to increase privacy, flexibility, and speed. Its creator argues that it can completely replace the CA system solely with browser-side adoption — although not everyone agrees.

Why anyone cares (or should...)

To review, the CA system is designed to foil a particular type of attack on SSL connections: the man-in-the-middle (MITM) attack, in which an attacker intercepts a browser connection destined for a secure site, makes its own connection to the secure site instead, and rewrites all traffic between the browser and the site — copying down the secrets it wants to steal, but otherwise invisibly maintaining the connection between the two endpoints. From both endpoints' point-of-view, the traffic would be encrypted.

Using the CA system, however, the browser first asks the server for its identity in the form of a certificate, and checks that the certificate is cryptographically signed by a trustworthy external authority, the CA. "Intermediate"-level CAs have their own certificates signed by parent CAs, eventually chaining all the way back to one of a select group of root CAs whose certificates are installed with the browser.

The trouble is that the entire framework hinges on those root CAs being impenetrable, which the recent Comodo and DigiNotar attacks prove is, sadly, not true. Attackers can break into a CA and use its secret key to sign rogue certificates of their own invention. There is also the possibility of CAs (or their employees) being subverted by criminals or governments to create rogue certificates. The signature on a rogue certificate checks out as authentic, hijacking the entire chain of trust.

Perspectives

Perspectives (and the Firefox extension that implemented it) was actually created to solve a slightly different problem: how to verify the identity of a self-signed certificate, which by its very nature cannot be checked against a "trusted" third-party CA. Instead, Perspectives relies on the collective judgment of a set of "notaries" — independent servers that request certificates from sites.

The browser queries multiple notaries about a particular certificate, and each one reports back a fingerprint of the certificate it gets from the site. If the notaries are on different routes to the server in question, and all see the same certificate, then the certificate is probably legitimate. The other possibility is that an attacker has taken over the routes between all of the notaries and the chosen server and is performing a MITM attack on each of them — in which case, the browser is simply up SSL Creek without a paddle. That type of false-positive is unlikely, however, and an attacker powerful to perform it (a national network backbone provider or government, perhaps) would be difficult to escape.

The Perspectives technique provides a way to check a self-signed certificate's authenticity courtesy of what the original paper calls "multi-path probing", but it has the nice property of providing similar authenticity assurances for CA-signed certificates, too. The implementation in the Firefox extension had its problems, however — it only performed notary verification for the initial HTTPS request, not subsequent elements like images and scripts, and there was a noticeable lag time between querying a notary and getting a response in return (which may in part be due to the notary re-requesting the certificate before responding). On top of that, it has simply not been regularly updated to work with ongoing Firefox builds, which periodically makes it unavailable for frequent updaters.

Convergence

At Black Hat 2011 in August, developer Moxie Marlinspike presented an extended version of the Perspectives technique he called Convergence. Convergence tackles both of the aforementioned issues directly, decreasing lag time through caching (although there does not appear to be any hard data comparing the speed of the two approaches), and checking all HTTPS requests through the notary mechanism. But it pushes the envelope in other ways as well.

First, although it could serve as a double-check mechanism for CA-verified certificates, Perspectives did not bypass Firefox's built-in CA verification system; Convergence replaces it entirely. This can even be seen in the UI: Firefox's standard "identity block" to the left of the location bar shows the name of the site and the CA used to verify its SSL certificate, while the Convergence extension replaces this information with "verified by Convergence" instead.

Marlinspike was also concerned about the privacy implications of Perspectives: notaries were in a position to track browser behavior by collecting the IP address (and other connection information) of each request and logging the SSL certificates it queried. Convergence attempts to guard against this by enabling each notary to serve in two distinct modes, either making SSL certificate queries, or acting as a relay (a function which Marlinspike calls a "bounce node").

In this scheme, when the browser needs to check a certificate, it first chooses a bounce node. Subsequently, the browser sends certificate queries to the bounce node, each destined for another notary and encrypted with the public key contained in that notary's ID "bundle", which is a publicly-accessible .notary file on the notary server. Which notary it chooses does not affect the protocol; it could be randomized for each query or the browser could select a personal favorite. The bounce node forwards the query to the notary (who decrypts and executes it), and forwards the notary's response back to the browser. Thus the bounce node knows who sent the query, but cannot read it, and the notary used knows what certificate is requested but not who asked, ultimately preserving the browser's anonymity. Using more than one notary is critical to both the Perspectives and Convergence approaches, but how many notaries are used in order to deem a certificate "verified" is left up to the user

The Convergence Firefox extension is available directly from the project web site, although, disconcertingly (and ironically, for a security project), it asks to install itself directly rather than offering a download link — or even a means to check the signature on the transmitted .xpi file. The extension source code is also available on Marlinspike's GitHub site, as is the notary server code. The server code is written in Python, uses SQLite, and requires only generating a key pair and an empty database to begin. Each notary is "advertised" with a publicly accessible JSON-formatted .notary file containing hostname and port information along with the notary's public key.

Users can add a new notary to their browser's list of alternatives by requesting (i.e., clicking on) the notary's .notary file. If they later decide that a notary is no longer trustworthy, it can be removed at will. In his talk, Marlinspike calls this "trust agility" and says it is an essential feature of any CA-replacement scheme. In practice, he observes, CA trust cannot be revoked, because doing so (even when a CA is shown to be unreliable, such as Comodo) cuts off access to thousands of legitimate and uncompromised sites. For now, the GitHub site also hosts a list of known notaries, numbering around 40. The extension itself comes with a pre-loaded set of notaries to get started with.

Marlinspike also emphasized in his talk that Convergence's user-controllable, multiple-notary system does not hinge solely on whether or not each notary uses the Perspectives approach. Instead, the key factor is that the user has control over a dynamic set of trusted notaries. Some notaries could attempt to verify sites through other means, including DNSSEC, and the framework would still function for users. The user is responsible for setting his or her own "threshold" for accepting or rejecting a site's identity, based on what the notaries report about it.

Problems and criticisms

Marlinspike argued that Convergence could replace the CA system entirely if the majority of browser vendors got behind it — chiefly because no change is required of site administrators; their existing SSL certificates function just as well in Convergence's identity check process as they do today. But the user-configurability and flexibility of the system that Marlinspike regards as Convergence's strong suit is seen as an inherent weakness by the Chromium/Chrome team.

Google's Adam Langley wrote a blog post about the issue in September. He claimed that user statistics indicate "99.99% of Chrome users would never change the default settings," and as a result, the default set of notaries shipped with the browser would need to offer extremely high uptime and handle a tremendous traffic load. That, in turn, would mean that "Google would end up running the notaries. So the design boils down to Chrome phoning home for certificate validation," and Convergence support is therefore something that Google is not interested in adding.

Langley also cited two problems that Convergence cannot currently overcome: connecting to "internal servers" and captive portals. Langley does not elaborate on internal servers, but probably means intranet services that cannot be queried by notaries outside the internal network. Captive portals are a bigger problem, because they are widespread in public WiFi hotspots. Specifically, the issue is that a captive portal intercepts all HTTP and HTTPS traffic before the client sign-on is complete, so the browser cannot contact any notaries to verify that the portal itself is who it claims to be and not a clever phishing site.

Marlinspike addressed captive portals at the end of his talk, in terms of a lingering open question. Based on his slides (which show hypothetical notaries run by personally-trusted organizations like the Electronic Frontier Foundation), he does not seem too concerned about Langley's claim that Google would end up shouldering the burden of operating the world's notaries. Marlinspike also referred to what he called "the Citibank problem", where the Citibank URL transparently redirects different HTTPS requests to different internal servers with separate SSL certificates, thus making it impossible for notaries to verify the certificate by making independent requests. He did not have a solution, but did point out that Citibank is the only site known to suffer from this problem.

But despite his concerns, Langley was not all negative; he praised the Convergence extension as something worthwhile for those who wish to use it, and said that by coding it, Marlinspike "has already done a thousand times more to address the problem than almost anyone else." For its part Mozilla seems equally non-committal towards including the Convergence system in the future. Daniel Veditz said in a comment on the Mozilla Security blog that he was "intrigued by the Perspectives/Convergence experiments and we're definitely watching to see how they work in practice and at scale. We have no plans to build either one into Firefox at this time." There does not appear to be any public comment on Convergence from either the Internet Explorer or Safari teams.

Regardless of whether or not it ever appears as a built-in option, reality is that users with a mistrust of the CA system can use Convergence today to completely replace the default certificate-verification mechanism in Firefox. For some, that will probably be enough. Unfortunately, since the Black Hat talk, there has been little in the way of developing Convergence further as an open source project. There is a mailing list that has only archived a few messages, and the documentation — particularly for the protocol — is sparse. There is clearly sufficient interest in replacing the CA system to spawn work on a distributed, open source solution, but whether it remains a niche service like Tor or survives to affect the mainstream Web is entirely up in the air.

Comments (3 posted)

Brief items

Security quotes of the week

-- Bruce Schneier

-- Gunter Ollmann about Duqu, "son of Stuxnet" in Dark Reading

-- Matthew Garrett's footnotes about Microsoft's Secure Boot implementation

-- Ed Bott misses the point

Comments (13 posted)

Garrett: Management of UEFI secure booting

Matthew Garrett reports on a proposed solution for the UEFI Secure Boot problem that was recently highlighted by the Free Software Foundation. "How does this avoid the problems associated with prompting the user to boot untrusted binaries? The first is that there's no problem with updates. Because a key has been imported, as long as future bootloader updates are signed with the same key, they'll boot without prompting the user. The second is that it can be limited to removable media. If malware infects the system and installs itself onto the hard drive, the firmware won't prompt for key installation. It'll just refuse to boot and fall back on whatever recovery procedures the OEM has implemented. The only way it could get on the system would involve the user explicitly booting off removable media, which would be a significant hurdle. If you're at that stage then you can also convince the user to disable secure boot entirely." LWN also took a look at the problem back in June.

Comments (14 posted)

New vulnerabilities

awstats: multiple vulnerabilities

Package(s):	awstats	CVE #(s):
Created:	October 19, 2011	Updated:	October 19, 2011
Description:	Multiple flaws were reported in current versions of AWStats' awredir.pl script. See the Red Hat bugzilla for details.
Alerts:	Fedora FEDORA-2011-14025 2011-10-09 Fedora FEDORA-2011-13999 2011-10-09

Comments (none posted)

conky: privilege escalation

Package(s):	conky	CVE #(s):	CVE-2011-3616
Created:	October 14, 2011	Updated:	October 19, 2011
Description:	From the Red Hat Bugzilla entry: A Debian bug report [1],[2] indicated that conky is vulnerable to an arbitrary file overwrite flaw. In the getSkillname() function of the Eve plugin, there is a race condition between when the plugin checks for the existence of /tmp/.cesf and when it writes to the file, easily beaten because getXmlFromAPI() is called in between (which can take time due to network latency, etc.). If a user were able to beat the race and create a symlink of /tmp/.cesf to any file the user running conky had write access to, they could overwrite the contents of that file.
Alerts:	Gentoo 201110-09 2011-10-13

Comments (none posted)

feh: arbitrary file creation

Package(s):	feh	CVE #(s):	CVE-2011-1031
Created:	October 14, 2011	Updated:	October 19, 2011
Description:	From the CVE entry: The feh_unique_filename function in utils.c in feh 1.11.2 and earlier might allow local users to create arbitrary files via a symlink attack on a /tmp/feh_ temporary file, a different vulnerability than CVE-2011-0702.
Alerts:	Gentoo 201110-08 2011-10-13

Comments (none posted)

java: multiple vulnerabilities

Package(s):	java-1.6.0-openjdk	CVE #(s):	CVE-2011-3521 CVE-2011-3544 CVE-2011-3547 CVE-2011-3548 CVE-2011-3551 CVE-2011-3552 CVE-2011-3553 CVE-2011-3554 CVE-2011-3556 CVE-2011-3557 CVE-2011-3558 CVE-2011-3560
Created:	October 19, 2011	Updated:	February 6, 2013
Description:	From the Red Hat advisory: A flaw was found in the Java RMI (Remote Method Invocation) registry implementation. A remote RMI client could use this flaw to execute arbitrary code on the RMI server running the registry. (CVE-2011-3556) A flaw was found in the Java RMI registry implementation. A remote RMI client could use this flaw to execute code on the RMI server with unrestricted privileges. (CVE-2011-3557) A flaw was found in the IIOP (Internet Inter-Orb Protocol) deserialization code. An untrusted Java application or applet running in a sandbox could use this flaw to bypass sandbox restrictions by deserializing specially-crafted input. (CVE-2011-3521) It was found that the Java ScriptingEngine did not properly restrict the privileges of sandboxed applications. An untrusted Java application or applet running in a sandbox could use this flaw to bypass sandbox restrictions. (CVE-2011-3544) A flaw was found in the AWTKeyStroke implementation. An untrusted Java application or applet running in a sandbox could use this flaw to bypass sandbox restrictions. (CVE-2011-3548) An integer overflow flaw, leading to a heap-based buffer overflow, was found in the Java2D code used to perform transformations of graphic shapes and images. An untrusted Java application or applet running in a sandbox could use this flaw to bypass sandbox restrictions. (CVE-2011-3551) An insufficient error checking flaw was found in the unpacker for JAR files in pack200 format. A specially-crafted JAR file could use this flaw to crash the Java Virtual Machine (JVM) or, possibly, execute arbitrary code with JVM privileges. (CVE-2011-3554) It was found that HttpsURLConnection did not perform SecurityManager checks in the setSSLSocketFactory method. An untrusted Java application or applet running in a sandbox could use this flaw to bypass connection restrictions defined in the policy. (CVE-2011-3560) An information leak flaw was found in the InputStream.skip implementation. An untrusted Java application or applet could possibly use this flaw to obtain bytes skipped by other threads. (CVE-2011-3547) A flaw was found in the Java HotSpot virtual machine. An untrusted Java application or applet could use this flaw to disclose portions of the VM memory, or cause it to crash. (CVE-2011-3558) The Java API for XML Web Services (JAX-WS) implementation in OpenJDK was configured to include the stack trace in error messages sent to clients. A remote client could possibly use this flaw to obtain sensitive information. (CVE-2011-3553) It was found that Java applications running with SecurityManager restrictions were allowed to use too many UDP sockets by default. If multiple instances of a malicious application were started at the same time, they could exhaust all available UDP sockets on the system. (CVE-2011-3552)
Alerts:	Debian DSA-2358-1 2011-12-05 SUSE SUSE-SU-2011:1298-1 2011-12-02 Debian DSA-2356-1 2011-12-01 Red Hat RHSA-2011:1478-01 2011-11-24 Mandriva MDVSA-2011:170 2011-11-11 Ubuntu USN-1263-1 2011-11-16 Fedora FEDORA-2011-15555 2011-11-07 Scientific Linux SL-java-20111019 2011-10-19 Gentoo 201111-02 2011-11-05 openSUSE openSUSE-SU-2011:1196-1 2011-10-28 Scientific Linux SL-java-20111018 2011-10-18 Fedora FEDORA-2011-14648 2011-10-20 Fedora FEDORA-2011-14638 2011-10-20 CentOS CESA-2011:1380 2011-10-19 Red Hat RHSA-2011:1384-01 2011-10-19 Red Hat RHSA-2011:1380-01 2011-10-18 Red Hat RHSA-2012:0006-01 2012-01-09 Red Hat RHSA-2012:0034-01 2012-01-18 SUSE SUSE-SU-2012:0114-1 2012-01-23 SUSE SUSE-SU-2012:0122-1 2012-01-26 Fedora FEDORA-2012-1690 2012-02-15 SUSE SUSE-SU-2012:0122-2 2012-02-23 SUSE SUSE-SU-2012:0114-2 2012-03-06 Red Hat RHSA-2012:0508-01 2012-04-23 SUSE SUSE-SU-2012:0602-1 2012-05-09 Fedora FEDORA-2012-16351 2012-10-18 Fedora FEDORA-2013-1898 2013-02-05

Comments (none posted)

krb5: multiple vulnerabilities

Package(s):	krb5	CVE #(s):	CVE-2011-1527 CVE-2011-1528 CVE-2011-1529
Created:	October 19, 2011	Updated:	January 5, 2012
Description:	From the Red Hat advisory: Multiple NULL pointer dereference and assertion failure flaws were found in the MIT Kerberos KDC when it was configured to use an LDAP (Lightweight Directory Access Protocol) or Berkeley Database (Berkeley DB) back end. A remote attacker could use these flaws to crash the KDC. (CVE-2011-1527, CVE-2011-1528, CVE-2011-1529) Red Hat would like to thank the MIT Kerberos project for reporting the CVE-2011-1527 issue. Upstream acknowledges Andrej Ota as the original reporter of CVE-2011-1527.
Alerts:	Fedora FEDORA-2011-14673 2011-10-20 Fedora FEDORA-2011-14650 2011-10-20 openSUSE openSUSE-SU-2011:1169-1 2011-10-24 Mandriva MDVSA-2011:160 2011-10-22 Mandriva MDVSA-2011:159 2011-10-22 Ubuntu USN-1233-1 2011-10-18 Scientific Linux SL-krb5-20111018 2011-10-18 Red Hat RHSA-2011:1379-01 2011-10-18 Debian DSA-2379-1 2012-01-04 Gentoo 201201-13 2012-01-23

Comments (none posted)

ldns: arbitrary code execution

Package(s):	ldns	CVE #(s):	CVE-2011-3581
Created:	October 19, 2011	Updated:	November 25, 2011
Description:	From the Red Hat bugzilla: It was reported that the ldns_rr_new_frm_str_internal() function of ldns, when parsing data of unknown RR types ("\#"), suffered from a boundary error. This could be exploited to cause a heap-based buffer overflow by parsing specially crafted DNS Resource Records, possibly leading to the execution of arbitrary code.
Alerts:	Debian DSA-2353-1 2011-11-24 openSUSE openSUSE-SU-2011:1161-1 2011-10-20 Fedora FEDORA-2011-13915 2011-10-07 Fedora FEDORA-2011-13929 2011-10-07

Comments (none posted)

libreoffice: arbitrary code execution

Package(s):	libreoffice	CVE #(s):	CVE-2011-2685
Created:	October 18, 2011	Updated:	November 14, 2011
Description:	From the CVE entry: Stack-based buffer overflow in the Lotus Word Pro import filter in LibreOffice before 3.3.3 allows remote attackers to execute arbitrary code via a crafted .lwp file.
Alerts:	Mandriva MDVSA-2011:172 2011-11-11 openSUSE openSUSE-SU-2011:1143-2 2011-10-18 openSUSE openSUSE-SU-2011:1143-1 2011-10-18 Ubuntu USN-1496-1 2012-07-02

Comments (none posted)

php: unspecified vulnerability

Package(s):	php5	CVE #(s):	CVE-2011-3268
Created:	October 17, 2011	Updated:	October 19, 2011
Description:	From the CVE entry: Buffer overflow in the crypt function in PHP before 5.3.7 allows context-dependent attackers to have an unspecified impact via a long salt argument, a different vulnerability than CVE-2011-2483.
Alerts:	Mandriva MDVSA-2011:165 2011-11-03 openSUSE openSUSE-SU-2011:1138-1 2011-10-17 openSUSE openSUSE-SU-2011:1137-1 2011-10-17 Mandriva MDVSA-2012:071 2012-05-10

Comments (none posted)

php: denial of service

Package(s):	php5	CVE #(s):	CVE-2011-3267
Created:	October 17, 2011	Updated:	October 19, 2011
Description:	From the CVE entry: PHP before 5.3.7 does not properly implement the error_log function, which allows context-dependent attackers to cause a denial of service (application crash) via unspecified vectors.
Alerts:	Mandriva MDVSA-2011:165 2011-11-03 Ubuntu USN-1231-1 2011-10-18 openSUSE openSUSE-SU-2011:1138-1 2011-10-17 Debian DSA-2408-1 2012-02-13 Mandriva MDVSA-2012:071 2012-05-10

Comments (none posted)

php: denial of service

Package(s):	php5	CVE #(s):	CVE-2011-1657
Created:	October 18, 2011	Updated:	October 19, 2011
Description:	From the Ubuntu advisory: Maksymilian Arciemowicz discovered that the ZipArchive functions addGlob() and addPattern() did not properly check their flag arguments. This could allow a malicious script author to cause a denial of service via application crash.
Alerts:	Mandriva MDVSA-2011:165 2011-11-03 Ubuntu USN-1231-1 2011-10-18 Debian DSA-2408-1 2012-02-13 Mandriva MDVSA-2012:071 2012-05-10

Comments (none posted)

phpPgAdmin: cross-site scripting

Package(s):	phpPgAdmin	CVE #(s):	CVE-2011-3598
Created:	October 13, 2011	Updated:	October 19, 2011
Description:	From the Red Hat Bugzilla entry: Multiple cross-site scripting (XSS) flaws were reported in phpPgAdmin: the 'title' argument of a particular web page was not sanitized properly prior displaying the page header, the return ULR ('return_url') and return link name ('return_desc') were not sanitized properly prior displaying the requested page data. A remote attacker could provide a specially-crafted URL, which once visited by an unsuspecting phpPgAdmin user could lead to arbitrary HTML or web script execution.
Alerts:	Fedora FEDORA-2011-13801 2011-10-05 Fedora FEDORA-2011-13805 2011-10-05 openSUSE openSUSE-SU-2012:0493-1 2012-04-12

Comments (none posted)

pidgin: denial of service

Package(s):	pidgin	CVE #(s):	CVE-2011-3594
Created:	October 14, 2011	Updated:	January 9, 2012
Description:	From the Red Hat advisory: An input sanitization flaw was found in the way the Pidgin SILC (Secure Internet Live Conferencing) protocol plug-in escaped certain UTF-8 characters. A remote attacker could use this flaw to crash Pidgin via a specially-crafted SILC message. (CVE-2011-3594)
Alerts:	Mandriva MDVSA-2011:183 2011-12-10 openSUSE openSUSE-SU-2011:1291-1 2011-12-01 Ubuntu USN-1273-1 2011-11-21 CentOS CESA-2011:1371 2011-11-09 CentOS CESA-2011:1371 2011-10-14 Scientific Linux SL-pidg-20111013 2011-10-13 Red Hat RHSA-2011:1371-01 2011-10-13 Fedora FEDORA-2011-17558 2011-12-30 Fedora FEDORA-2011-17546 2011-12-30 Gentoo 201206-11 2012-06-21

Comments (none posted)

quassel: insecure installation permissions

Package(s):	quassel	CVE #(s):
Created:	October 14, 2011	Updated:	October 19, 2011
Description:	From the Ubuntu advisory: Felix Geyer discovered that the quassel-core post installation script created data and logging directories which were readable by all users. The post installation script also generated a certificate, in the data directory, which was readable by all users.
Alerts:	Ubuntu USN-1230-1 2011-10-14

Comments (none posted)

tomcat: authentication bypass

Package(s):	tomcat	CVE #(s):	CVE-2011-3190
Created:	October 17, 2011	Updated:	February 2, 2012
Description:	From the CVE entry: Certain AJP protocol connector implementations in Apache Tomcat 7.0.0 through 7.0.20, 6.0.0 through 6.0.33, 5.5.0 through 5.5.33, and possibly other versions allow remote attackers to spoof AJP requests, bypass authentication, and obtain sensitive information by causing the connector to interpret a request body as a new request.
Alerts:	CentOS CESA-2011:1780 2011-12-22 Scientific Linux SL-tomc-20111205 2011-12-05 Oracle ELSA-2011-1780 2011-12-05 Red Hat RHSA-2011:1780-01 2011-12-05 Ubuntu USN-1252-1 2011-11-08 Fedora FEDORA-2011-13457 2011-09-29 Mandriva MDVSA-2011:156 2011-10-18 openSUSE openSUSE-SU-2011:1134-1 2011-10-17 Debian DSA-2401-1 2012-02-02 Gentoo 201206-24 2012-06-24 Mageia MGASA-2012-0189 2012-08-02

Comments (none posted)

tomcat: multiple vulnerabilities

Package(s):	tomcat5	CVE #(s):	CVE-2011-1184
Created:	October 18, 2011	Updated:	August 10, 2012
Description:	From the Mandriva advisory: The implementation of HTTP DIGEST authentication in tomcat was discovered to have several weaknesses.
Alerts:	CentOS CESA-2011:1780 2011-12-22 CentOS CESA-2011:1845 2011-12-20 Oracle ELSA-2011-1845 2011-12-20 Scientific Linux SL-tomc-20111220 2011-12-20 Red Hat RHSA-2011:1845-01 2011-12-20 Scientific Linux SL-tomc-20111205 2011-12-05 Oracle ELSA-2011-1780 2011-12-05 Red Hat RHSA-2011:1780-01 2011-12-05 Ubuntu USN-1252-1 2011-11-08 Fedora FEDORA-2011-15005 2011-10-27 Mandriva MDVSA-2011:156 2011-10-18 Debian DSA-2401-1 2012-02-02 SUSE SUSE-SU-2012:0155-1 2012-02-07 openSUSE openSUSE-SU-2012:0208-1 2012-02-09 Oracle ELSA-2012-0474 2012-04-12 Gentoo 201206-24 2012-06-24 Mageia MGASA-2012-0189 2012-08-02 Fedora FEDORA-2012-7593 2012-08-09 Fedora FEDORA-2012-7258 2012-08-09

Comments (none posted)

unbound: denial of service

Package(s):	unbound	CVE #(s):	CVE-2010-0969
Created:	October 17, 2011	Updated:	October 19, 2011
Description:	From the CVE entry: Unbound before 1.4.3 does not properly align structures on 64-bit platforms, which allows remote attackers to cause a denial of service (daemon crash) via unspecified vectors.
Alerts:	Gentoo 201110-12 2011-10-15

Comments (none posted)

xorg-server: xserver locking vulnerabilities

Package(s):	xorg-server	CVE #(s):	CVE-2011-4028 CVE-2011-4029
Created:	October 18, 2011	Updated:	July 11, 2012
Description:	Two vulnerabilities have been discovered in the code handling the X server lock that forbids two X servers from serving the same display simultaneously. This X.org advisory has the details.
Alerts:	SUSE SUSE-SU-2011:1292-1 2011-12-02 Gentoo 201110-19 2011-10-22 Ubuntu USN-1232-2 2011-10-19 Ubuntu USN-1232-1 2011-10-18 openSUSE openSUSE-SU-2012:0227-1 2012-02-09 Red Hat RHSA-2012:0303-03 2012-02-21 Oracle ELSA-2012-0303 2012-03-07 Scientific Linux SL-xorg-20120321 2012-03-21 Red Hat RHSA-2012:0939-04 2012-06-20 Oracle ELSA-2012-0939 2012-07-02 Scientific Linux SL-xorg-20120709 2012-07-09 CentOS CESA-2012:0939 2012-07-10

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The current development kernel is 3.1-rc10, released on October 17. "There really hasn't been all that much going on - the smallish MIPS updates are still the bulk of this -rc, and the rest is pretty much small driver fixes. Oh, and some last-minute fs (btrfs and xfs) fixes in there too." Expect the final 3.1 release sometime in the near future.

Stable updates: the 3.0.7 update was released on October 17 with a moderately-sized set of important fixes.

Comments (2 posted)

Quotes of the week

-- Neil Brown

-- Peter Zijlstra

-- Matthew Garrett

Comments (1 posted)

2011 Kernel Summit draft agenda posted

The 2011 Kernel Summit will be held on October 24 and 25 in Prague. The draft agenda has been posted. Needless to say, LWN will be reporting from the event; stay tuned.

Full Story (comments: 1)

Answers to some common kernel.org account questions

A new FAQ file has posted in response to questions that have been raised about the process of getting back onto kernel.org. It's worth a read for those who have not yet reestablished their access. "At this time, we are only providing access to developers who previously hosted git repositories on kernel.org, and whose repositories have shown activity after February, 2011. At a later time we will be able to consider creating accounts for developers with inactive trees or who have not had a kernel.org account in the past."

Full Story (comments: none)

Another kernel RAID5 implementation

There are many things that the kernel lacks, but RAID implementations is not on that list. Both the MD and DM subsystems currently have full RAID support, while the Btrfs filesystem has lower-level RAID support. RAID5/6 support for Btrfs has been posted a couple of times, but has not yet made it into the mainline. So, one might well be justified in wondering if yet another RAID5 implementation is needed in the kernel.

There will be one if Boaz Harrosh has his way; his RAID5 support patch has been posted to a few filesystem-related kernel development lists. Boaz's patch is aimed at adding RAID5 support to the "objects raid engine" code in the exofs filesystem, which provides a POSIX filesystem on top of object-storage devices. It also implements RAID5 for the pNFS object-storage backend.

According to Boaz, this work constitutes a nice, general-purpose RAID library that could be used in other settings; in particular, he says, Btrfs could make use of it. What would be even nicer, of course, is if some of the existing in-kernel RAID implementations could also move to this library - or if exofs could use one of those implementations. This version of RAID5 support may well be cleaner and more general than the others, but it may well take a stronger argument than that to get a new RAID subsystem merged at this point.

Comments (9 posted)

Kernel development news

Yet another opportunity for opportunistic suspend

Your editor was innocently looking at some papers on his desk the other day when his computer abruptly decided to suspend itself. Rawhide is fun in that way; combined with GNOME's delight in forgetting user settings, it can produce no end of surprises to brighten one's working experience. The ability to suspend a desktop system to RAM is actually quite a nice feature, but your editor prefers to have a say in when it happens. Thankfully, GNOME still (so far) allows automatic suspend to be turned off. But it is clear that the suspend-to-RAM functionality is seeing increased use in a number of contexts; it is not just for laptops and Android anymore. Your editor's desktop is not the only place where stakeholders want some control over when the system sleeps and when it needs to stay running.

Indeed, control over automatic suspension of the system is at the core of the debate over Android's opportunistic suspend mechanism. As usage of suspend-to-RAM increases, so does interest in creating a proper mechanism for determining when a suspend can happen. A new patch set from Rafael Wysocki has restarted this discussion and led to, possibly, a surprising conclusion.

Rafael started with the conclusion that "whatever the kernel has to offer in this area is either too complicated to use in practice or inadequate for other reasons." He then went on to propose a new mechanism that, he hoped, would simplify things. It came in two parts:

• A new sysfs knob, /sys/power/sleep_mode, which provided overall control of the suspend-to-RAM and hibernation functionality. If a suitably-privileged process writes "disabled" to this file, no attempt to suspend or hibernate the system will succeed. It is a sort of high-power wakelock that ensures the system will keep running while important work is being done.

• Applications wanting to keep the system awake would open a new device, /dev/sleepctl, and execute an ioctl() to that effect. After this call, attempts to suspend the system would block until the application explicitly drops its lock or until a 500ms (by default) timeout period expires. The "stay awake" operation would also be done by the system at resume time to give processes time to perform whatever tasks need to be done.

It is probably safe to say that these patches will not be merged in anything resembling this form. Leading the opposition was Neil Brown, who asserted that the job could be done in user space, and, indeed, should be done that way. According to Neil:

Communication with that process, Neil claimed, should be no harder than using Rafael's simplified interface to communicate with the kernel. After a fair amount of discussion, Neil came up with a proposal for how he thinks things should actually work. As one would expect from the above quote, it centers around a single daemon with the responsibility for suspending and resuming the system. A decision to suspend the system is never made by the kernel, and, if everybody is following the rules, by no other user-space process.

The daemon has a pair of modes; it starts in the "on demand" mode where the system will only be suspended after an explicit request to do so. That request could come from the user closing the lid or pressing a button sequence; in this case, the system should suspend in short order regardless of what is happening, and it should not resume without an explicit user action. Suspend can also be requested by a suitably-privileged application; in this case the operation is only carried out if nothing is blocking it, and the system can be automatically resumed at some future time. This mode was also referred to as the "legacy" mode; it needs to be supported but it is not how things are expected to run most of the time.

Other processes in the system can affect suspend behavior by talking to the daemon. One of the things a sufficiently-privileged process can do is to ask the daemon to go into "immediate" mode; in that mode, the system will suspend anytime there is no known reason to stay awake. The immediate mode, thus, closely mirrors the opportunistic suspend mechanism used on Android systems. When the daemon is in immediate mode, it no longer makes sense for any process in the system to ask the system to suspend - the daemon is already prepared to suspend whenever the opportunity arises. So the rest of the interface is concerned with when the system should be awake.

Any process with an interest in suspend and resume events can open a socket to the daemon and request notification anytime a suspend is being contemplated. That process should respond to such notifications with a message saying that it is ready for the suspend to happen; it can, optionally, add a request that the system stay awake for the time being if there is work that must be done. If no processes block the suspend, the system will go to sleep; another message will be sent to all processes once the system resumes.

There is an interesting variant on this mechanism whereby processes can register one or more file descriptors with the daemon. In this case, the daemon will only query the associated processes before suspending if one or more of the given file descriptors is reported as readable by poll(). A readable file descriptor thus functions in a manner similar to a driver-acquired wakelock in the Android system. If a device wakes the system and provides input for a user-space process to read, the daemon will see that the file descriptor is readable and avoid suspending the system until that input has been consumed and acted upon. Meanwhile, processes that clearly have no need to block suspend will not need to wake up and respond to a notification every time a suspend is contemplated.

The daemon also allows processes to request that the system be awake at some future time. A tool like cron can use this feature to, say, wake the system late at night to run a backup.

At a first glance, this approach looks like it should be able to handle the opportunistic suspend problem without the need to add more mechanism to the kernel. But it must be remembered that this is a problem that has defeated a number of initially reasonable-looking solutions. Whether this proposal will fare better - and whether the various desktop and mobile environments will adopt it - remains to be seen.

Comments (11 posted)

Timer slack for slacker developers

The "timer slack controller" is a proposed mechanism that would allow a session management program to adjust the timer tolerances of a group of processes with a single knob. It seems like a relatively obscure and harmless feature, but it has been the focus of an intense debate on the kernel mailing lists. The core question has been seen before: what measures should the kernel take, if any, to keep poorly-written applications from hurting performance?

Timers allow a process to request a wakeup at some future time; timer slack gives the kernel some leeway in its implementation of those timers. If the kernel can delay specific timers by a bounded amount, it can often expire multiple timers at once, minimizing the number of wakeups and, thus, reducing the system's power consumption. Some processes need more precise timing than others; for this reason, the kernel allows a process to specify its maximum timer slack with the prctl() system call. There is, currently, no mechanism to allow one process to adjust another process's timer slack value; it is generally assumed that any given process knows best when it comes to its own timing requirements.

The timer slack controller allows a suitably privileged process to set the timer slack value for every process contained within a control group. The patch has been circulating for some time without generating a great deal of interest; it recently resurfaced in response to the "plumber's wish list for Linux" which requested such a feature. The reasoning behind the request was explained by Lennart Poettering:

It is, in other words, a power-saving mechanism. When the session manager determines that nothing special is going on, it can massively increase the slack on any timers operated by desktop applications, effectively decreasing the number of wakeups. Applications need not be aware of whether the user is currently at the keyboard or not; they will simply slow down during the boring times.

There is some stiff opposition to merging this controller. Naturally, the fact that the timer slack controller uses control groups is part of the problem; some kernel developers have still not made their peace with control groups. Until that situation resolves itself - if it ever does - features based on control groups are going to have a bumpy ride on their way into the mainline.

Beyond the general control group issue, though, two complaints have been heard about this approach to power management. One is that applications running on the desktop may have timing requirements that are not dependent on whether the user is actually there or not. One could imagine a data acquisition application that does not have stringent response requirements, but which will still lose data if its timers suddenly gain multiple seconds of slack. Lennart's response is that such applications should be using the realtime scheduler classes, but that answer is unlikely to please anybody. There is likely to be no shortage of applications that have never needed to bother with realtime scheduling but which still will not work well with arbitrary delays. Imposing such delays could lead to any number of strange bugs.

The big complaint, though, as expressed by Peter Zijlstra and others, is that this feature makes it easier for developers to get away with writing low-quality applications. If the pressure to remove badly-written code is removed, it is said, that code will never get fixed. Peter suggests that, rather than papering over poor behavior in the kernel, it would be better to simply kill applications that waste power. He was especially strident about applications that continue to draw when their windows are not visible; such problems should be fixed, he said, before adding workarounds to the kernel.

The massive improvements in power behavior that resulted from the release and use of PowerTop is often pointed to as an example of how things should be done. This situation is a little different, though. The wakeup reductions inspired by PowerTop were low-hanging fruit - processes waking up multiple times per second for no useful purpose. The timer slack controller is aimed at a different problem: wakeups which are useful when somebody is paying attention, but which are not useful otherwise. That is a trickier problem.

Determining when the user is paying attention is not always straightforward, though there some obvious signs. If the screen has been turned off because the input devices are idle, the user probably does not care. Other cases - non-visible tabs in web browsers, for example - have been cited as well, but the situation is not so obvious there. As Matthew Garrett put it: buried tabs still need timer events "because people expect gmail to provide them with status updates even if it's not the foreground tab." Fixing the problem in applications would require figuring out when nothing is going on, finding a way to communicate it to applications, then fixing large numbers of them (some of which are proprietary) to respond to those events.

It is not surprising that developers facing that kind of challenge might choose to improve the situation with a simple kernel patch instead. It is, certainly, a relatively easy path toward better battery life. But the patch does raise a fundamental policy question that has never been answered in any definitive way. Does mitigating the effects of (what is seen as) application developer sloppiness encourage the distribution of low-quality code and worsen the system in the long run? Or, instead, does the "tough love" approach deter developers and impoverish our application environment without actually fixing the underlying problems?

An answer to that question is unlikely to come in the near future. What that probably means is that the current fuss will be enough to keep the timer slack controller from getting in through the 3.2 merge window. It also seems unlikely to go away, though; we are likely to see this topic return to the mailing lists in the future.

Comments (58 posted)

Limiting system calls via control groups?

Limiting the system calls available to processes is fairly hot topic in the kernel security community these days. There have been several different proposals and the topic was discussed at some length at the recent Linux Security Summit but, so far, no solution has made its way into the mainline. Łukasz Sowa recently posted an RFC for a different mechanism to restrict syscalls, which may have advantages over other approaches. It also has a potential disadvantage as it uses a feature that is unpopular with some kernel hackers: control groups.

Conceptually, Sowa's idea is pretty straightforward. An administrator could place a process or processes into a control group and then restrict which syscalls those processes (and their children) could make. The current interface uses system call numbers that are written to the syscalls.allow and syscalls.deny cgroup control files. Any system calls can be denied, but only those available to a parent cgroup could be enabled that way. Any process that makes a denied system call would get an ENOSYS error return.

Using system call numbers seems somewhat painful (and those numbers are not the same across architectures), but may be unavoidable. But there are some other bigger problems, performance to begin with. Sowa reports 5% more system time used by processes in the root cgroup, which is a hefty penalty to pay. His patch hooks into the assembly language syscall fastpath, which is probably not going to fly. It is also architecture-specific and only implemented for x86 currently. Paul Menage points out that hooking into the ptrace() path may avoid those problems:

Menage also mentions some other technical issues with the patch, but he is skeptical overall of the need for it. "I'd guess that most vulnerabilities in a system can be exploited just using system calls that almost all applications need in order to get regular work done (open, write, exec ,mmap, etc) which limits the utility of only being able to turn them off by syscall number." Because the approach only allows a binary on or off choice for the system calls, he doesn't necessarily think that it has the right level of granularity. The granularity argument echoes the one made by Ingo Molnar on a 2009 proposal to extend seccomp by adding a bitmask of allowed system calls.

But there have been a number of projects that have expressed interest in having a more flexible seccomp-like feature in the kernel, starting with the Chromium browser team who have proposed several ways to do so. Seccomp provides a way to restrict processes to a few syscalls (read(), write(), exit(), and sigreturn()), but that is too inflexible for many projects. But Molnar has been very vocal in opposition to approaches that only allow binary decisions about system call usage, and he prefers a mechanism that filters system calls using Ftrace-style conditionals. That approach, however, is not popular with some of the other tracing and instrumentation developers.

It is a quandary. There are a number of projects (e.g. QEMU, vsftpd, LXC) interested in such a feature, but no implementation (so far) has passed muster. Sowa's cgroup-based solution may well be yet another. Certainly the current performance for processes that are not in a cgroup (i.e. are in the root cgroup) is not going to be popular—an understatement—but even if Menage's suggestion (or some other mechanism) leads to a solution with little or no performance impact, there may be complaints because of the unpopularity of cgroups.

There may be hope on the horizon in the form of a proposed discussion about expanding seccomp (or providing a means to disable certain syscalls) at the upcoming Kernel Summit, though it does not seem to have made it onto the agenda. Certainly many of the participants in the mailing list discussions will be present. Control groups is on the agenda, though, so there will be some discussion of that rather contentious topic. Look for LWN's coverage of the summit on next week's Kernel page.

Comments (7 posted)

Patches and updates

Kernel trees

• Linus Torvalds: Linux 3.1-rc10 . (October 18, 2011)

• Greg KH: Linux 3.0.7 . (October 17, 2011)

• Thomas Gleixner: 3.0.7-rt20 . (October 19, 2011)

• Thomas Gleixner: 3.0.6-rt18 . (October 14, 2011)

Core kernel code

• Cyrill Gorcunov: [RFC] Checkpoint/restore and Elf extension . (October 14, 2011)

• Rafael J. Wysocki: PM / Sleep: Extended control of suspend/hibernate interfaces . (October 17, 2011)

Development tools

• Stephane Eranian: perf_events: add support for sampling taken branches (v2) . (October 14, 2011)

• Mel Gorman: MMTests 0.02 . (October 17, 2011)

• Alex Elder: xfstests v1.1.0 . (October 17, 2011)

• Steven Rostedt: ktest updates for v3.2 . (October 17, 2011)

Device drivers

• chris@cnpbagwell.com: Add support for new (3rd generation) Bamboo P&T's. . (October 17, 2011)

• Barry Song: dmaengine: add CSR SiRFprimaII DMAC driver . (October 17, 2011)

• Linus Walleij: drivers: create a pin control subsystem . (October 17, 2011)

• Jonathan Cameron: IIO: Out of staging step 1: The core . (October 17, 2011)

• Andy Fleming: Add support for 10G to PHY Lib . (October 17, 2011)

• Ricardo Ribalda Delgado: Add spi support for CMA3000 driver and new driver CMR3000 . (October 18, 2011)

• cloud.ren@atheros.com: alx: Atheros AR8131/AR8151/AR8152/AR8161 Ethernet driver . (October 19, 2011)

Documentation

• Christoph Hellwig: XFS status update for September 2011 . (October 14, 2011)

Filesystems and block I/O

• Boaz Harrosh: ore: RAID5 Support . (October 17, 2011)

• Aneesh Kumar K.V: New ACL format for better NFSv4 acl interoperability . (October 18, 2011)

• Tejun Heo: fix request_queue life-cycle management . (October 19, 2011)

Memory management

• Suleiman Souhlal: [PATCH 0/4] memcg: Kernel memory accounting. . (October 17, 2011)

Networking

• Glauber Costa: Request for inclusion: tcp memory buffers . (October 14, 2011)

• Hans Schillstrom: NETFILTER new target module, HMARK . (October 17, 2011)

Architecture-specific

• Matt Fleming: x86 EFI boot stub . (October 17, 2011)

• Daniel J Blueman: Add Numachip APIC support . (October 18, 2011)

• Tim Bird: ARM 4Kstacks: introduction . (October 19, 2011)

Security-related

• Dmitry Kasatkin: evm: digital signature verification extension . (October 14, 2011)

• Lukasz Sowa: cgroup: syscalls limiting subsystem . (October 19, 2011)

Virtualization and containers

• Jeremy Fitzhardinge: Paravirtualized ticketlocks . (October 17, 2011)

Page editor: Jonathan Corbet

Distributions

Creating a Fedora ARM distribution part 1: History

[Editor's note: this is the first of a two-part series on the creation of a Fedora distribution for the ARM architecture, contributed by Red Hat developer Jon Masters. This segment covers the history leading up to the current effort; part 2 will look at how the Fedora ARM distribution was bootstrapped and where things will go from here.]

The Fedora distribution is often associated with laptops and desktops using x86 processors. These systems are cheap, powerful, and readily available to developers, and so it would naturally follow that they would be well supported. But Fedora has long supported systems based upon architectures other than the venerable x86. Such systems include those using PowerPC (and its bigger cousin, POWER), SPARC, and even mainframe processors. Collectively, these alternatives are known in the Fedora nomenclature as secondary architectures, and they have historically tended to target more niche users (the number of readers owning a mainframe is likely small).

What makes the ARM port different than many of the existing Fedora secondary architectures is that ARM-based hardware is, like x86, cheap, readily available to developers, and is increasingly becoming more powerful. It has not yet reached the level of a high-end x86 desktop or laptop, but decent performance can be had from an embedded board or netbook system costing under $200. The latest systems use dual core ARM Cortex-A9MP processors such as the OMAP4 from Texas Instruments, or the Tegra2 from Nvidia, with more-capable processors on the horizon. Each of these systems feature around 1GB of RAM, a decent amount of storage options, and good network connectivity, along with a host of peripheral devices.

The availability of inexpensive ARM-based hardware gives rise to an interest in distribution support from those who wish to ship such hardware to end users and developers. Companies like Marvell have been active in the early support of Fedora as a means to enable popular "Plug" Computers such as the SheevaPlug, GuruPlug, and DreamPlug built using Marvell's ARMv5-based Kirkwood and later processors. Interest in a Fedora port to the ARM architecture does not come only from those selling microprocessors. Projects such as OLPC (One Laptop Per Child) already use Fedora on x86 and will have an easier migration path to ARM if they can remain using the same distribution.

A history of Fedora ARM

The Fedora ARM project has had several beginnings over the years. At first, the work was mostly driven by hardware manufacturers or those owning specific ARM-based systems with an interest in running Fedora on them. Those were good efforts, but their narrow focus meant that the project remained a fairly niche effort. Today, the Fedora ARM project is independent of any one hardware company, software company, or even target system. Instead, it is formed from a diverse (and growing) group of developers with shared interests in ARM technology. The team includes faculty and students of Seneca College in Toronto, employees of Red Hat, members of the existing Fedora community, and individuals from several continents. Some are using embedded ARM boards like the PandaBoard, TrimSlice and GuruPlug, others are using netbooks and next generation OLPC prototypes, but all have one collective interest in seeing ARM recognized as a first-class citizen within the Fedora family.

Fedora ARM had its earliest beginning in the form of an initial project sponsored by Marvell. Marvell makes the Kirkwood chip and its successors, which power many of the popular "plug computing" devices on the market. The development was based largely on still earlier work done by Lennert Buytenhek, a (former) Marvell employee who had made substantial progress on his own time. This led to several successful releases of various packages and filesystem images in the Fedora 8-12 timeframe, sufficient to gain a small following among those using Marvell's devices. Many early problems were solved at this time, including adding the necessary support within Fedora's package management tools (RPM, Yum, and so on) to recognize ARM architectures, as well as various small (and some not so small!) patches to core distribution packages to handle the differences between ARM and x86. Although Marvell discontinued its project following Fedora 12, it proved very valuable as a starting point for the effort that would follow.

The project as it exists today began in early 2010 when Chris Tyler of Seneca College in Toronto and a small group of his students picked up where Marvell had left off. Together with members of the Fedora community (and including the valiant efforts of Fedora release engineer Dennis Gilmore), Seneca created and hosted an instance of the Koji build system software used to build all Fedora packages, along with a large number of ARM-based build systems. Just like with other secondary architecture teams, the Fedora ARM project builds every software package using systems running on the target architecture rather than (for example) cross-compiling for a specific target architecture on x86. The rationale behind this approach is complex and best saved for another article, but it is a strategy supported by those working on the Fedora ARM port. Builds are performed using Koji, a distributed build management system, which drives individual builder systems running a build-in-chroot tool known as mock.

Building Fedora 13 for ARM

With the new build infrastructure, the Seneca team was able to orchestrate the mass building of Fedora 13 packages, taking the exact versions of source packages from the existing primary architecture (x86) as their input. In the case of some packages that had never been built for Fedora 13, even on the primary architecture, older versions (fortunately available from the Marvell effort) were used instead. Once the building of packages had been completed, an instance of the Fedora signing server was setup for ARM and a signed set of packages was released. Fedora 13 thus represented the most complete release yet, both in terms of packages, and in terms of the overall release management process, following very closely that used by the primary x86 architecture. The release was well received by the small (but seemingly growing) base of users, and was installed on popular embedded boards as well as various ARM netbooks.

The Fedora 13 release lacked two key components that will be eventually required for ARM to gain more widespread use amongst Fedora users. The most obvious omission was a standard Linux kernel package, of the kind that is present for every other architecture. A lot of work is ongoing in the wider Linux ARM community to allow a single binary kernel to support many different systems (through the use of device tree and similar platform device enumeration technologies, as well as industry standardization efforts), but in the interim it is still necessary to make some choices during kernel build that limit the ability for a distribution to ship a one-size-fits-all kernel. Instead, the need of a shorter term solution lead to several kernels being made available for Fedora 13 (based upon one source kernel package), each targeting a family of processors, and having names like kernel-omap, kernel-tegra2, and so on.

The Fedora ARM user had to manually choose the correct kernel for their system, but the number of users was still relatively small and was mostly confined to developers or those willing to experiment. Besides, the Fedora 13 release lacked an installer, so installation typically involved building a filesystem containing the desired packages and kernel combination. The lack of a generic installation option was in part because nobody had gotten around to getting the Fedora installer built properly and in part because of the lack of widely deployed platform standards for ARM systems, meaning that there was no one way to install and configure a system to boot Fedora automatically. Many embedded ARM systems (but by no means all) use U-Boot, however there are many flavors of U-Boot today, each of which is configured differently, and none of which has a standard mechanism for upgrading the kernel from an installed system.

In the future, installation of generic operating systems like Fedora should improve as newer standards such as UEFI become more prevalent on ARM. This will allow for a full, general-purpose installer such as Fedora's Anaconda to support ARM to the same extent that it supports x86 today. In the interim though, the Fedora ARM project has chosen to make a few assumptions around the use of U-Boot and provided a means to specify the location of the images required to boot through the means of a configuration file. This allowed the project to at least provide several kernel packages that could be configured to install for a range of possible target systems and bootloader choices. A number of filesystem images were shipped for specific systems in lieu of having a full installer such that it is possible to download a Fedora 13 image built for one of the popular embedded boards and get going quickly.

Fedora 13 for ARM is (still) technically the current release, although all development is now focused on getting Fedora 15 finished. For those who just want to quickly investigate an older release, Fedora 13 is available in the form of a filesystem that can be downloaded via the "Releases" section of the Fedora ARM wiki. It can be unpacked onto an SD card (for example) and installed onto a target system, along with the appropriate kernel for the chosen target. A number of pre-created images are also available, for example targeting the Texas Instruments PandaBoard (and using device tree during the boot process). Following installation, standard tools such as yum can be used to install various additional packages.

Reflections upon the Fedora 13 release

Fedora 13 for ARM was released and subsequently installed on many different systems. For a (short) period of time, updates were made available based on builds being done for the primary architecture, but the fun was relatively short-lived as Fedora primary moved on to the F15 release, which meant that, under Fedora policy, support was officially discontinued for the older F13 release. This gave the Fedora ARM team an opportunity to reflect upon the realities of continuing to trail the primary architecture. In the longer term, this would hinder the ability to reach the goal of becoming a primary architecture by virtue of being too out of date for consideration.

Fortunately for the Fedora ARM project, relief would come in the form of a mass rebuild of packages for the primary architecture. Whereas many releases of Fedora will include packages from older releases that have not been touched in the interim, various changes at the core distribution level necessitated that every package be rebuilt for Fedora 15 on all architectures. This meant that there was no need to carry any Fedora 14 (or earlier) packages in the final Fedora 15 ARM release provided that the set of Fedora 15 packages could be successfully rebuilt without them (or by building only interim throwaway Fedora 14 packages to aid in the mass rebuild effort). Therefore, the project had an opportunity to largely skip Fedora 14 and head full steam ahead toward a Fedora 15 release. Mass rebuilds certainly benefit secondary architecture releases and it is hoped that they will become Fedora policy.

Another reason for skipping over Fedora 14 and focusing on Fedora 15 alone came in the form of growing interest in supporting newer ARMv7-based processors. The existing Fedora 13 packages had targeted ARMv5, which was fine in 2007 when the project first started, but was increasingly becoming a performance issue by 2010. In the interceding years, there had been first the ARMv6 architecture (with SMP support) and then ARMv7. With ARMv7 came not only core architectural improvements such as more heavily-optimized instruction streams and virtualization extensions but also mandated support for VFPv3 (Vector Floating Point) hardware. To accompany this requirement, ARM introduced a newer Application Binary Interface (ABI) revision to the Procedure Call Standard for the ARM Architecture (AAPCS) specific to ARMv7 and higher systems that improves performance (especially when using floating point), but at the expense of a one-time break with backward compatibility.

A new ARM Architecture

Typically, ARM architecture improvements are backward compatible since ARM recognizes the value in supporting the code deployed for the billions of ARM-based devices in the wild. It would have been possible for Fedora to build ARMv5 packages that would support both older and newer processors, but at the cost of losing some of the architectural improvements and ABI changes that can be leveraged by targeting only v7. Thus, Fedora 15 could have continued to use software floating support as had been the case historically and left the newer ABI for the future. But instead, it was decided to capitalize on the mass rebuild being performed in Fedora 15 and treat ARMv7 as an entirely new architecture. A new architecture featuring a new ABI that was not compatible with older ARM processors would require a build (bootstrap) of every package in any case. Treating ARMv7 as a new architecture also allowed Fedora to progress while continuing to support older ARM processors through a separate ARMv5 build.

Breaking backward compatibility is never an easy choice, as anyone who has weighed the merits of the newer x32 ABI can likely attest, but there are times when its impact can be reduced. This was especially true in the case of the Fedora ARM project, which doesn't (yet) have an installed base of many millions of users and so could afford a one time inconvenience to the (mostly developer) user base in order to reap the many benefits of having a standardized base going forward. The newer ABI, known informally within the community as the "hard float" ABI has quite a following and the various Linux distributions have agreed to work together to develop a stronger base of inter-distribution binary compatibility. It has also been agreed to pursue standardization in the Linux Standard Base around ARMv7.

Moving to a new ABI is in general a non-trivial operation because it means that all of the software in the entire Fedora distribution must be rebuilt from scratch. In this respect, moving to the new ABI is similar to moving to a new architecture, which is how the transition to ARMv7 was approached. Fortunately, in this case there was already a working Linux kernel because only the userspace linkage of applications was actually being changed. The kernel itself only cares about the system call interface ABI, which wasn't affected by the change. Therefore, in this particular case (though this is not true in general of new architecture ports) it was possible to run both of the userspace ABI versions on the same kernel, even concurrently. Fedora can do this using different user-space chroots, while some other distributions are experimenting with something they call "multi-arch" which uses different dynamic linker prefixes according to the ABI version. Fedora ARM will aim to be compatible with this approach by virtue of the cross-distribution standardization effort (though it may in the short term use a symlink approach targeting one arch with the standard prefixes in the absence of full multi-arch support).

[The second part of this series will be available in the near future.]

Comments (12 posted)

Brief items

OpenMediaVault 0.2 released

The first OpenMediaVault release is available. OpenMediaVault is a Debian-based distribution aimed at network-attached storage applications; it is derived from FreeNAS. More information can be found on the OpenMediaVault wiki.

Comments (5 posted)

Ubuntu 11.10 (Oneiric Ocelot) released

The Ubuntu 11.10 release is available. "For PC users, Ubuntu 11.10 supports laptops, desktops and netbooks with a unified look and feel based on an updated version of the desktop shell called 'Unity', which introduces specialized 'Lenses'. Finding and installing software using the Ubuntu Software Centre is now easier thanks to improvements in speed, search functionality enhancements, and usability improvements. Aside from updates on the performance side, it's also more aesthetically appealing." See the release notes for more information.

Full Story (comments: 31)

Distribution News

Debian GNU/Linux

delegation for the DSA team

The Debian Systems Administration team has two new members: Faidon Liambotis and Tollef Fog Heen. They will join team members Luca Filipozzi, Martin Zobel-Helas, Peter Palfrader, and Stephen Gran.

Full Story (comments: none)

Ubuntu family

Precise open for development

The next version of Ubuntu "Precise Pangolin" aka 12.04 is open for development. Currently syncs are underway from Debian testing in preparation for this Long Term Support (LTS) release.

Full Story (comments: none)

Newsletters and articles of interest

Distribution newsletters

• DistroWatch Weekly, Issue 427 (October 17)
• Maemo Weekly News (October 17)
• openSUSE Weekly News 197 (October 16)
• Ubuntu Weekly Newsletter, Issue 237 (October 16)

Comments (none posted)

At Home With AV Linux (Linux Journal)

Dave Phillips takes a look at AV Linux, a Debian based distribution aimed at Audio/Video creation. "In the lower left corner of the opening display you'll see a row of icons. The icon at far left summons the main menu for the AV Linux applications stack and system maintenance tools. As mentioned, you'll find all the major players in the Linux audio applications arena, from Ardour to ZynAddSubFX, along with a generous helping of video applications and utilities. System administration tools can be found in the main menu, or you can simply click on the AV Linux Control Panel, the icon just to the right of the main menu's icon. The Control Panel provides easy access to tools and utilities for system management, administration, and customization. Its amenities include an installer for ATI/nVidia binary video drivers and a very useful tool that scans and analyzes your system for its readiness for realtime performance."

Comments (none posted)

Linux Mint developers make GNOME 3 edition plans (The H)

Linux Mint stayed with GNOME 2 for its last release. The H looks at plans for a GNOME 3 edition for the upcoming version 12 release. "The new edition will initially be developed alongside the GNOME 2.32-based release which will remain as the default desktop environment of Mint. The developers had decided to stick with GNOME 2.32 because there had been "radical changes" in GNOME 3.x's desktop which had split the communities of GNOME and Mint users."

Comments (8 posted)

Puppy Linux 5.2 "Wary" released (The H)

The H covers the release of Wary Puppy 5.2, a popular "puplet" for older hardware. "Based on the 2.6.32.45 Linux kernel, and with all of its base packages recompiled in the T2 System Development Environment, the new release is a "massive upgrade" to the 5.1.x series. Users can now easily upgrade from Xorg 7.3, which is still included by default to support older hardware, to version 7.6 for newer video devices by installing a single PET (Puppy's Extra Treats) package. Because of several problems, the gtkam GTK2 GUI for libgphoto2 has been replaced with PupCamera for automatically detecting digital cameras."

Comments (none posted)

Page editor: Rebecca Sobol

Development

Martus: Software for human rights groups

What constitutes a hostile environment for software? For one Martus user in Colombia, it meant being held up at gunpoint one evening after leaving work and being forced to hand over her laptop. Without Martus, doing so may have placed the lives of a large number of people in danger. Thanks to Martus, she could hand over the computer secure in the knowledge that these people were safe.

Martus (from the Greek for "Witness") is a fairly simple program - it records reports of human rights abuses ("bulletins" in Martus terminology), encrypts them, and stores them securely off site. But given the circumstances under which it's used, it is vital that its users have an absolute confidence that it does those things well.

At the recent Open World Forum in Paris, I had the opportunity to talk with Dr. Jeff Klingner of Benetech, the US-based non-profit that wrote Martus. Jeff was speaking in the "Humanitarian Free and Open Source Software" track at the conference. He mentioned that "NGOs [Non-governmental organizations] who use Martus have confidence in the security of our software because it's open source". Because records are stored encrypted by Benetech, "they don't even have to trust us" - something Jeff admitted was a concern for some NGOs around the world.

Security before convenience

Martus is designed for ease of use, but whenever security concerns come into conflict with usability, security wins through. One example: there is no key recovery service. If you lose your private key or forget your passphrase, any data encoded with that key is lost. Benetech has put a lot of effort into educating its users about best security practices - there is an entire chapter of the Martus user guide [PDF] dedicated to safe computing, guarding against malware and handling passwords. Martus also includes an onscreen keyboard for password entry, to help defend against key-sniffer malware.

Martus is written in Java, and licensed under the GPL. It consists of two distinct parts: a server which stores encrypted bulletins, and a client, which provides for data entry, search and encoding of bulletins.

Each Martus user has their own key and passphrase, which is used to encrypt all data they enter into the system. In addition, users may set up a HQ account, so that others who you trust in your organization will be able to see your private data, once you have sent it to the server. Bulletins are also kept encrypted on the local hard drive until they are deleted by the user.

Internally, keypairs are 2048-bit RSA keys that are encrypted with SHA1 and TwoFish using a passphrase. All bulletin data is encrypted with 256-bit AES, and signed using SHA1 digests and the private key. And all client-server communications are transferred using SSL with self-signed certificates. The team have considered using biometrics or physical objects to complement passphrases and private keys, but according to Benetech engineer Kevin Smith, the Martus Technical Lead, "whenever we have researched biometric authentication, we have not been comfortable with the reliability and security, and/or with the impossibility of changing your credentials if they become compromised".

Releasing the software as open source has not been a panacea for the project. Jeff Klingner notes that "we have been asking for a security audit by the open source community for years, but to our knowledge no-one has done one." Just because the project is open source does not mean that people are reading or reviewing the source code. He did mention that he suspected that some governments may have taken a look at the software, but (unsurprisingly) did not share the results of their review.

So what is the basis for Martus's users trusting the software? In the absence of a security review, isn't there a chance of a Haystack-style security flaw? Jeff says:

In addition to their track record, Jeff also pointed to the core team members, Kevin Smith and Scott Weikart. Scott in particular "has a totally paranoid approach to security and dreams up security threats that would never have occurred to me. The Martus data servers are locked up tighter than any other Linux security configuration I have ever seen" according to Jeff.

Several other things make Jeff confident that Martus will not see a Haystack-like security vulnerability uncovered. Firstly, Martus is open, while Haystack was not. Secondly, Benetech are very clear what is and is not being protected against - and are frank about their potential failings. According to Jeff, "even though we've been as careful as I think it's possible for people to be, we also understand and openly acknowledge the very real possibility that we've made an important security mistake. This fact comes through in Martus's documentation, and in the way we present Martus to potential users".

Part of the reason for the lack of community traction could be how difficult it is to get hold of the software on Linux. There are no packages available for either RPM or .deb based systems, either for the server or client components. Binary distributions for Windows, Mac, and Linux are available from the project's download page, but there was a server problem when I tried to download the latest version of the client software. Source code is available directly on the project's sourceforge page, but I have not been able to find the project developers' mailing list. The project could definitely provide a better experience for developers, and if they do, there are a lot of easy ways for people to help, including packaging, translations, and security review.

Social coding for good

In addition to Martus, Benetech also runs a number of other projects in the areas of human rights, literacy, and environmental protection. To attract new contributors to these and other humanitarian software projects, the company recently launched a new initiative, Social Coding 4 Good, to increase awareness of these projects and to put potential contributors in contact with projects that can use their help. Jeff mentioned that he believed that a lot of young programmers would like to give time to a project which is both technically challenging and provides some social benefit - Social Coding 4 Good aims to fill that gap, in a way similar to what HFOSS does for academic programs.

More and more, people are interested in working on "stuff that matters", to use a phrase made famous by Tim O'Reilly. Projects like Martus, that can make a real difference during times of political turmoil in some of the most troubled regions of the world, offer an opportunity to do something that matters. If you want to help with the project, report a security bug or propose packaging the software for your Linux distribution, you can contact the project at info at martus.org.

Comments (5 posted)

Brief items

Quotes of the week

-- Nick Coghlan

-- Richard Stallman

-- Asa Dotzler

Comments (7 posted)

Apache Cassandra 1.0

Version 1.0 of the Apache Cassandra distributed key-value data store is out. New features include on-disk compression, better memory management, and a lot of performance improvements.

Comments (none posted)

IcedTea 2.0 and security fixes

IcedTea 2.0 has been released. "This release is the first release of IcedTea based on OpenJDK7 since it was released for general availability. It includes all changes from the public OpenJDK7 tree, together with the latest security fixes and a number of IcedTea enhancements." For those running older versions of IcedTea, versions 1.8.10, 1.9.10, and 1.10.4 are available with several security fixes.

Full Story (comments: none)

Announcements from the LibreOffice conference

The Document Foundation has sent out an email that highlights some of the announcements from the LibreOffice conference, which is being held in Paris October 12-15. Two of those are "advanced development projects" that will become available in 2012 or 2013: LibreOffice Online and ports of the office suite to Android and iOS. In addition: "500.000 desktops, mostly Windows, at several French Government entities switching from OpenOffice to LibreOffice (this increases the Windows installed base of LibreOffice by 5% in a single move)."

Full Story (comments: 22)

Samba-VirusFilter 0.1.0 released

Samba-VirusFilter is a new project to integrate various malware scanners with the Samba server. Version 0.1.0 is out with support for ClamAV, F-Secure, and Sophos scanners.

Full Story (comments: none)

The STEED project launches

STEED is a project to create "usable end-to-end encryption" using GnuPG. It features automatic key generation and distribution and a "trust on first contact" trust model. More information can be found in this white paper [PDF].

Full Story (comments: none)

SyncEvolution 1.2 released

Version 1.2 of SyncEvolution, a personal information management and synchronization application, is out. The headline feature appears to be support for the CalDAV and CardDAV protocols, with ActiveSync support in the works for the 1.3 release. Support for Akonadi and KWallet has also been added.

Full Story (comments: none)

xpra 0.0.7.28 released

From the Xpra web site: "Xpra is 'screen for X': it allows you to run X programs, usually on a remote host, direct their display to your local machine, and then to disconnect from these programs and reconnect from the same or another machine, without losing any state." The 0.0.7.28 release adds a number of significant performance improvements, forwarding of system notifications, and more.

Full Story (comments: none)

Newsletters and articles

Development newsletters from the last week

• Caml Weekly News (October 18)
• Perl Weekly (October 17)
• PostgreSQL Weekly News (October 16)
• Tahoe-LAFS Weekly News (October 10)
• Tahoe-LAFS Weekly News (October 16)

Comments (none posted)

Lopez: The next million apps

On his blog, Xan Lopez looks at the GNOME app story and comes to a familiar conclusion: "Why is this relevant for GNOME? Never mind iOS, never mind Android, one thing is clear: most of the next million apps written will be web applications. Some huge players like Microsoft are already moving there as fast as they can, and the rest will follow sooner or later. Native apps won't go anywhere for a long time, but developers willing to maximize their reach will, increasingly, prefer web applications over anything else. At least as their first choice. This brings us a great opportunity. If we jump on this bandwagon, support web applications as first class citizens on top of world-class runtimes, and accept and even encourage people to run their web apps on our operating system we can maximize our reach with a fraction of the effort of fighting in the native SDK war against Apple and Google."

Comments (35 posted)

Poettering: [Google code search is] A Big Loss

Lennart Poettering covers a Google announcement that Google Code Search will shut down in January. "I think it must be of genuine interest to the Free Software community to have a capable replacement for Google Code Search, for the day it is turned off. In fact, it probably should be something the various foundations which promote Free Software should be looking into, like the FSF or the Linux Foundation. There are very few better ways to get Free Software into the heads and minds of engineers than by examples -- examples consisting of real life code they can find with a source code search engine. I believe a source code search engine is probably among the best vehicles to promote Free Software towards engineers. In particular if it itself was Free Software (in contrast to Google Code Search)." (Thanks to Paul Wise)

Comments (26 posted)

Schumacher: Fifteen years of KDE

Cornelius Schumacher reflects on 15 years of KDE on his blog as well as looking to the future for the KDE "desktop" (which is moving well beyond the traditional desktop these days). "Fifteen years ago Matthias Ettrich started the KDE community. On 14th October 1996 he wrote his famous email to the de.comp.os.linux.misc group on Usenet. He called for other programmers to join him to create a free desktop environment for Linux targeted at end users. Many, many people joined. Thousands of developers wrote millions lines of code. We did 90 stable releases of our core set of applications alone, not counting all additional stuff and the thousands of 3rd party applications."

Comments (2 posted)

Page editor: Jonathan Corbet

Announcements

Brief items

The Android 4.0 SDK available

The Android 4.0 software development kit is now available for download; source code will seemingly have to wait for a while longer yet. The Android 4.0 platform highlights page has an overview of what's in this release for those who are interested. "Android 4.0 introduces a completely new approach to securing a device, making it even more personal - Face Unlock is a new screen-lock option that lets users unlock their devices with their faces. It takes advantage of state-of-the-art facial recognition technology to register a face and to recognize it later when unlocking the device. Users just hold their devices in front of their faces to unlock, or use a backup PIN or pattern."

Comments (76 posted)

The Apache Software Foundation statement on Apache OpenOffice.org

The Apache Software Foundation has felt the need to put out a lengthy statement on the status of OpenOffice.org as an Apache project. "As with many highly-visible products, there has been speculation and conjecture about the future of OpenOffice.org at Apache. More recently, destructive statements have been published by both members of the greater FOSS community and former contributors to the original OpenOffice.org product, suggesting that the project has failed during the 18 weeks since its acceptance into the Apache Incubator. Whilst the ASF operates in the open - our code and project mailing lists are publicly accessible - ASF governance permits for projects to make information and code freely available when the project deems them ready to be released. Apache OpenOffice.org is not at risk."

Comments (12 posted)

Dennis Ritchie RIP

Via Rob Pike we learn that Dennis Ritchie has passed away. He laid the foundations for much of what we are doing now, and will be much missed.

Comments (75 posted)

Articles of interest

Colebourne: Time zone database rebooted

On his blog, Stephen Colebourne reports that the timezone database is available again at a new location [FTP]. This is in response to the lawsuit that shut down the Olson time zone database. "I think that all this energy once again demonstrates the value of open source communities and their resilience to difficulties when the code/data really matters to a wide cross-section of people. Thanks to everyone involved in [providing] that energy and spreading news of the attack. [...] However, none of us must forget Arthur David Olson and Paul Eggert, who still face the threat of a direct and personal lawsuit having given so much to the open community for zero cost and zero reward. I look forward to hearing better news for them personally." More information can also be found in a post by Robert Elz who has been spearheading the effort to find a new home for the database.

Comments (5 posted)

New Books

A Bug Hunter's Diary--New from No Starch Press

No Starch Press has released "A Bug Hunter's Diary" by Tobias Klein.

Full Story (comments: none)

Head First HTML5 Programming--New from O'Reilly Media

O'Reilly Media has released "Head First HTML5 Programming" by Eric Freeman and Elisabeth Robson.

Full Story (comments: none)

Early release of Embedded Android

O'Reilly Media has made available an early release of "Embedded Android" by Karim Yaghmour.

Comments (none posted)

Upcoming Events

SCALE_10X: SCALE Kids Conference announced

The Southern California Linux Expo (SCALE) will be hosting the SCALE Kids Conference during SCALE 10X. The Kids Conference will be on January 21, 2012, in the middle of the January 20-22 main event. "The goal of the conference is to be as "kid driven" as possible. The event offers a unique opportunity for kids 10 to 16 to see and experience the inner workings of planning, determine the content, and help to steer the direction that the conference will take."

Full Story (comments: none)

Events: October 27, 2011 to December 26, 2011

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

Date(s)	Event	Location
October 24 October 28	18th Annual Tcl/Tk Conference (Tcl'2011)	Manassas, Virgina, USA
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 12	Zentyal Summit	Zaragoza , Spain
November 11 November 13	Free Society Conference and Nordic Summit 2011	Gothenburg, Sweden
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 7	SciPy.in 2011	Mumbai, India
December 4 December 9	LISA ’11: 25th Large Installation System Administration Conference	Boston, MA, USA

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

Page editor: Rebecca Sobol