It took a while and some questioned whether it would ever happen at all,
but, on November 14, Google announced
the availability of the source for version 4.0.1 ("ice cream sandwich") of
the Android open source
project. This news has been received with a fair amount of celebration,
but also with a certain amount of criticism. Now might be a good time to
think a bit about how Android interacts with the open source community and
whether all of our expectations are where they should be.
What is there not to like about this release? One obvious problem is that
it was so long in coming; there has not been a major Android release since
2.3 came out in December, 2010. Since then, the Android code (with the
exception of the relatively small parts covered by the GPL license) has
been developed and kept behind closed doors. Google's reasons for
withholding the source have been explained and examined many times; some
find them reasonable, while others do not. But it seems clear that the end
result - no Android releases for almost a year - was not a good thing.
Complaints have also been heard about Google's refusal to provide tags for
the "Honeycomb" release that was shipped on a handful of devices. The
official reasoning is that Honeycomb was "a little incomplete" and that
Google would rather see people focusing on the 4.0 release. A focus on the
current code seems likely to happen naturally; it is hard to imagine that a
whole lot of people will be interested in going through the pain of turning
an old and "incomplete" version of the source into something that actually
runs on a device when something newer is available. But there may well be
people who want to reproduce something like the current binary installation
on their devices before proceeding to something newer. Removing the tags
and forcing those people to dig through the history for an appropriate
commit does seem like a bit of gratuitous obnoxiousness.
On the other hand, if Google had really wanted to be difficult, it could
have squashed out that history altogether.
People often complain that Android is not a real open source project. Such
assertions are hard to argue against. Android's governance is very much
controlled by its owning company. Releases of source are routinely
withheld, albeit not usually for as long as was the case for 4.0. To gain
access to the current source - to build a new product, for example -
requires being a Friend of Google and agreeing to its requirements. The
code contains certain antifeatures, such as applications that cannot be
the inability to use cell-tower-based location services without reporting
back to the mothership, that would probably not exist in a truly free
project. And so on; Android clearly works differently than most true,
community-oriented free software projects.
It is worth pointing such things out so that we are all clear on exactly
what the Android project is. It can even make sense to grumble about them
occasionally in the hopes that gentle pressure might cause some things to
change over time. But there also comes a time to simply accept Android for
what it is and make the best of it.
Let us remember that Android represents a gift of a vast amount of code
that is truly free software. That code has become the basis for more open
projects like CyanogenMod, where people have done some very fun things with
it. The advent of Android has coincided with the arrival of a whole range
of devices that are far more open than their predecessors. We now carry
powerful computers with broadband network connections in our pockets, and
we actually have some control over what runs on those computers. Anybody
who wants to build a new platform with Android's capabilities has the
software available to them, free of charge and free to modify.
Linux was doing well in the embedded world before Android; now it is
pushing toward a point of world dominance. Manufacturers design devices with
the idea that they will run Linux from the outset, and, increasingly, their
work is flowing back into the mainline kernel as well. Android may be far
from a traditional Linux distribution, but it's a base that is entirely
capable of running real Linux applications for those who want to do so.
If Android had shoved aside a viable "real Linux" platform in the handset
and tablet space, there might be at least a small basis for complaint. But
it would be hard to argue that platforms like OpenMoko or MeeGo would have
succeeded if Android had not come along and hogged the spotlight. For
better or for worse, nobody has managed to put together an alternative
Linux-based platform that has seen any adoption by the hardware vendors,
and that's not Android's fault.
In fact, even now, there would appear to be space for another mobile
platform. Admiration for Android is not universal, and manufacturers would
love to have another viable option for their products; it should be possible
to establish another contender. There are plenty of Linux-based projects
trying to become that contender; the GNOME and KDE projects both have their
eyes on that market, and Canonical evidently does as well. Whether any of
them (or somebody else) can pull together an offering that succeeds there
remains to be seen. Let us hope they can; it would be a shame if that
space were to be occupied by another fully proprietary system instead.
Meanwhile we do have Android, and Android, for all its faults, is a gift of
great value. It often seems that, as a community, we behave most harshly
toward those who contribute the most to us. Let's not stop talking about
how Android could be a better project from the community's point of view,
but let's also not forget to say "thank you" for all that it is. With the
4.0 release, we once again have a whole bunch of code that we can do great
things with; that merits a big "thanks!" from us all.
Comments (10 posted)
Some effects of the kernel.org break-in were immediate, but
others have rippled out more slowly. One example of the latter is the
system administration team taking a hard look at the security of its own
infrastructure. The team is drafting a plan to tighten down access to its
servers and looking at the development processes of the project
with the module upload process.
Olav Vitters sent an email to the GNOME desktop-devel list on November
10 that outlines a plan to preemptively secure the master.gnome.org server
against some preventable compromise paths. His root concern was that more than
350 GNOME developers have shell access, which provides a large attack
surface even though most (if not all) of those accounts are used only to
upload tar packages — a process that could be more securely performed
in other ways. Considering the lengthy process that the kernel.org team
had to undertake to restore the server after its compromise, the concern is
a very real one.
The GNOME project maintains a variety of public-facing services on different machines (Bugzilla, mailing lists, wikis, web sites, etc.), which are managed by one full-time system administrator paid by the GNOME Foundation, and assisted by a small team of volunteers. Vitters is one of those volunteers. His message to the list, which he styled as an IETF-like "request for comments" (RFC), targeted just one service: the FTP server used to distribute GNOME tarballs.
In the current FTP release process, package maintainers upload tarballs to a GNOME project server using SCP, then log in over SSH and execute an "install-module" script. The script calculates the checksum(s) of the newly-uploaded package(s), copies them to the proper location in the public FTP directory, and triggers another script that starts an FTP sync between the GNOME project server and the "real" master FTP server (which is located off-site) and the official mirrors.
Restricted SSH and DOAP
Due to the interactive SSH step, Vitters said, if any of the 350-or-so
package maintainers has their personal machine compromised, an attacker
could gain shell access to the GNOME project FTP server. That was the path
used by the kernel.org attackers, who then presumably used a local
privilege escalation to completely compromise the machine. It is very
probable that one or more of the GNOME user's machines has been
compromised, but that has evidently not led to unauthorized access to the GNOME
Vitters proposed a replacement module-upload plan, in which the initial file transfer would be performed with rrsync (the Perl-based program that restricts rsync to a pre-determined subdirectory) over an SSH tunnel. The user would then call a revised version of the install-module script remotely over SSH, where the SSH daemon on the server was configured to only permit execution of that script, rather than a full shell.
The server-side scripts already in use would also be modified to check the user account that uploaded the new file against a list of approved uploaders for the module, taken from the module's Description of a Project (DOAP) file. DOAP is an RDF format used to define the semantics of a project and its team; GNOME already stores DOAP files for each module in the project's Git repository.
The primary benefit of the plan is that it eliminates the need for the 350+ shell accounts. Even if a module maintainer's home machine is compromised, keeping the server locked down so that remote shell access is unavailable makes it more difficult to wreak large-scale havoc. It would still be possible to replace a package, but the identity check performed against DOAP would, in theory, mean that the attacker could only replace a small subset of packages for the majority of accounts. This is an improvement, because currently anyone with a shell account on the server can upload any package.
Vitters posed several questions for the list, starting with whether or
not the proposed process was so much more arduous than the existing system
that it would meet with resistance. But he also pointed out potential
technical hurdles such as uncertainty over the reliability of rsync,
whether rsync could be used to delete files, and the fact that although
most GNOME modules have a DOAP file in Git, those GNOME modules
that are not tracked using Git do not.
Reaction and feedback
Maciej Marcin Piechotka asked whether scp might be preferable to rsync, and suggested that the Git DOAP files are not secure, because anyone with Git access could upload a new DOAP file — a change less likely to be noticed by others than is the upload of a new tarball. Vitters replied that he considered, but ruled out, scp and sftp for the upload step because both permitted more file operations than rsync alone. In the interest of "just allowing exactly what is needed," he said, rsync was the better fit. "I don't want people to be able to modify anything [other] than uploading a tarball." He confirmed the vulnerability of the DOAP file in Git, and proposed modifying the upload scripts to notify existing maintainers whenever the DOAP file is modified.
Ray Strode then weighed in against restricting uploads to individuals in the DOAP file on the grounds that there are a lot of less-actively-maintained modules, and an unpredictable set of users who periodically need to make releases of them. "I think the lack of fine grained ACLs for this sort of thing is one part of GNOME that work better than projects that try to lock things down more aggressively," he said. Matthias Clasen and Bastien Nocera added that they were two such users, who occasionally update maintenance-mode modules when a change in such a module is mandated by an update to one of their own modules.
Vitters then suggested that the allowed-user-list could include the maintainers of each module plus all members of the release team, since both Clasen and Nocera are on the release team. Clasen and Nocera seemed happy with that adjustment, but Strode did not:
What I'm saying is there shouldn't be a lot of process involved here, because people informally help out pretty frequently. If you keep track of it already you can see probably see how often it happens by looking at the stats, I guess. A number of modules are sort of "maintained by the masses". It's not just release-team members who do the releases, either.
Strode's concern is not easily reconcilable with the overall plan,
because it boils down to a philosophical, not a technical question: how
locked-down is too locked-down.
lax security policy towards the less-frequently-updated modules
simplifies the work for the administrators and allows more people to
contribute, but the less-active modules are an easier target for
attackers. Inserting malicious code into an actively-developed module
is likely to get noticed in short order; by instead inserting it into a
nearly-forgotten Makefile that is still pulled in and executed when
one accomplishes the same goal with less risk of getting caught.
Alan Cox suggested that the team take a look at the tools used by the kernel.org team, which went through much the same locking-down process in September and October in response to the August break-in.
Lessons from kernel.org
The kernel.org lockdown began with the same concern as Vitters' RFC: eliminating the several-hundred shell accounts used mainly for uploading. Since the break-in, H. Peter Anvin has developed a suite of utilities for kernel.org that implement much the same process that Vitters is pursuing for the GNOME FTP server. Namely, allowing secure uploads, with access control measures limiting what individual users can upload, and without requiring shell access on the receiving machine. Anvin's work is the kernel.org upload tool, or "kup." It includes an upload client called kup and a server-side script called kup-server.
The kup-server script needs to be modified for each user
account, to specify the pathnames for allowable uploads, Git trees, lock
files, and the user's public keyring. The keyring file is read-only, and
is used to verify signatures; kup-server checks that uploads are
signed with a trusted OpenPGP key. Establishing the trust between the
identities and keys was one of the lengthiest parts of bringing kernel.org
Beyond simply utilizing a custom client instead of rsync, there are other differences, between kup and the GNOME.org proposal. The kup client contains multiple levels of sanity checks, even dry-running the requested commands in order to trap errors. It also supports other file operations in addition to uploads, including deletion, moving/renaming files, and creating links.
In addition, David Woodhouse said that he has set up a two-factor authentication scheme for kernel.org that has not yet been rolled out. It requires that users have both an SSH key and a one-time-password (OTP) generated by Google Authenticator. Google Authenticator includes a PAM module to secure applications, and a collection of OTP generators for various mobile phone OSes.
As of press time, Vitters told
the list that he had gotten in touch with Anvin to follow-up about
kup, but has not yet announced any alterations to the GNOME FTP
proposal based on those conversations. The kernel.org team learned the
hard way how much hassle a break-in on an upload server can produce.
Although other, somewhat lower-profile projects may not present nearly as
enticing an objective for attackers, they can learn from its example, and
it is good to see GNOME undertaking a preventative lock-down. One hopes
that the project is also taking steps to ensure that its infrastructure is
not already compromised as well.
Ultimately a more secure infrastructure may inconvenience package
maintainers, system administrators, and developers that (like Strode)
prefer a less formal structure, but for a project of any size, what other
choice is there? Package uploading and verification requires a security
policy; it is too inviting of a target to not lock it down.
Comments (3 posted)
Sabayon Linux, the easy-to-use Linux distribution built on top of Gentoo Linux, recently announced three new experimental editions that supplement their previous GNOME, KDE, Xfce, and Core releases. Two of the new experimental editions are equipped with unsurprising desktop environments: LXDE and E17 (Enlightenment). The third desktop choice, however, is surprising: the awesome window manager.
Awesome is no stranger to me: I have been using it for three years as the window manager on my main work computer because it's highly configurable and visually minimalistic, so I can focus on my work without any distractions. It's not so surprising that awesome isn't popular, as it's going up against modern desktop environments like GNOME 3, KDE 4 and Unity. In contrast to those desktop environments, awesome doesn't want to appeal to non-expert users, doesn't offer an Apple-like experience, and doesn't come with all kinds of bells and whistles. This makes it even more interesting that a mainstream distribution like Sabayon chose to include an edition with awesome.
A framework window manager
Awesome is called "a highly configurable, next generation framework window manager for X" by its developers. By "framework window manager" they mean that users actually build their own window manager with awesome: while it's usable with the default configuration, it is meant to be extended and configured by the user. Because of this, awesome is primarily targeted at power users, developers, and anyone who wants to have fine-grained control over their graphical environment. In contrast, if you don't like tweaking your system or if you like out-of-the-box bells and whistles, awesome probably isn't for you.
Awesome has a small code base and memory footprint and is fast. Because
it's using the asynchronous XCB
library instead of the synchronous Xlib, it also promises less latency than
other window managers, at least according to the home page. It prides itself on implementing many Freedesktop standards, such as EWMH (Extended Window Manager Hints) that allows programs to give hints to the window manager about the type of their windows, Desktop Notification to provide popup notifications on the desktop, System Tray to display small icons provided by running applications, and D-Bus for interprocess communication. And it even supports multiple monitors in XRandR, Xinerama, and Zaphod mode. So while it's a minimalist window manager, it doesn't fall short in its features.
Everyday working with awesome
By default, awesome has a simple but already quite usable configuration
that will even support multiple monitors. When you start an awesome X session, you'll see a minimalist desktop with a status bar on top of the screen. Awesome can be controlled completely with the keyboard, so you'll have to memorize some keyboard shortcuts to become proficient at it. For instance, Win+Enter opens a new terminal window (Win is the key with the Windows logo, called Mod4 in awesome's documentation and configuration file), Win+j cycles through the windows, Win+h or l resizes a window (but Win+right-click and dragging with the mouse is a bit more convenient), Win+Shift+j or k moves a window (as does Win+left-click and dragging with the mouse). With Win+Shift+c you close the focused window. Starting a program is simple: enter Win+r, after which you see a "Run:" prompt in the status bar and you can type a program name (with tab completion). It pays to read ~/.config/awesome/rc.lua a bit to get to know all these keyboard shortcuts. When you're used to them, awesome lets you really manage your windows in a very efficient way.
By default, awesome behaves like a regular stacking window manager, but
it started as a tiling window manager and I still find this mode the most
efficient to use. Just click on the icon in the upper right to use the
tiled layout. When you open your first window, it covers the whole screen,
and subsequently opened windows are tiled automatically alongside the other
windows, so the available screen real estate is always covered completely unless you have no windows open. By default, the most recent window is shown at the entire left part of the screen and the other ones are automatically rearranged on the right side. You don't have to juggle with your windows to get the most out of your screen; awesome does the job for you. By the way, there are no title bars attached to the windows by default, although you can change that in the configuration file.
The status bar at the top of the screen shows nine numbers by default at its leftmost part. If you click on one of them, you get a completely empty screen, ready to contain some new windows. Superficially, this looks like the workspace concept in many other desktop environments, but in awesome they are called tags and the relationship is backwards: while a workspace contains windows, in awesome tags belong to a window. This means that a single window can have multiple tags, but you can also view multiple tags together by right-clicking on another tag in the status bar. The nine tags can be reconfigured to have more descriptive names, although you probably should keep them short. For instance, I have tags "read", "talk", "surf", "type", "file", "hear" and "root". All in all, the concept of tags is much more flexible than traditional workspaces.
To the right of the tag list comes the task list, which is the list of
windows on the currently visible tag(s). To the right of that, there's the
clock, and at the rightmost part of the status bar is the layout box which
we already mentioned earlier. If you click on it, the way in which awesome
arranges all visible windows changes. You can cycle through all available
layouts with left-click (forward) and right-click (backward) or by using Win+Space. There's a spiral layout, a maximized layout (which only shows the focused window), a fullscreen layout (which even covers the status bar), a magnifier layout (which shows the focused window in the middle and the other ones on the background) and a floating layout, which shows all windows free-floating and covering each other, like you're used to from stacking window managers.
You can also toggle the floating/tiled status of the focused window with Win+Ctrl+Space and you can configure awesome to automatically force specific programs (like GIMP) to always float. You can also set the default layout programmatically in the configuration file. For instance, I have set the layout of my left screen to tiled and the layout of my right screen (which stands in portrait mode) to tiled.bottom, which tiles the windows vertically. This kind of personalization is very easy to do in awesome.
Tuning your desktop environment
Awesome is just a window manager, so, by default, a lot of functionality
offered by a complete desktop environment will be missing. But most of this
functionality can be added to the configuration file or supplemented by
external programs. The upside is that you can pick your components: you can
for instance choose lightweight alternatives. The downside is that you have
to configure a lot of things that come out-of-the-box with a desktop
environment such as GNOME or KDE and you have to add many programs to your
awesome key bindings or to your ~/.xinitrc before you have a
working desktop environment with things like an automounter, a file manager, a
network applet or
a screen shot program. You can also add widgets to
the status bar, e.g. a systray, graphs of the memory or CPU usage, and so on.
If you like the complete desktop environment that GNOME or KDE is offering and you just want to swap their default window manager for awesome, that's also possible. This gives you your familiar desktop environment, but with the much more flexible window management functionality of awesome. Have a look at the wiki on how to set up awesome with GNOME or with KDE.
Some programs have to be tuned to be able to use them well with awesome. For instance, if someone mentions you on IRC when you're using the irssi client, the tag associated with your irssi client can become orange (or whatever color you have configured in your awesome theme) by setting up a couple of things. There are also some problems with Java programs when you use a Java virtual machine older than version 1.7, but most issues can be overcome.
Awesome began in September 2007 as a fork of dwm, an extremely minimalist window manager which can only be customized through editing its source code (all options meant to be user-configurable are contained in a single header file). Debian developer Julien Danjou liked dwm's minimalism, but wanted it to have an external configuration file. In version 3.0, he decided to use the programming language Lua for the configuration file format.
Danjou is still the primary author of
awesome, but there are a lot of other contributors, and Uli Schlachter
maintains awesome now. After a frantic development speed the first two
years, development has slowed down now, with the latest release, 3.4.10,
being made on May 16 along with a rather low number of commits in the
project's repository. In an email interview, Danjou said that the reason for the slowdown is simple:
Awesome is rather complete. It misses a few things,
but there's enough to do what people want. The fact is that the X protocol
part about window management doesn't evolve, so once it's implemented and
exposed to users so that they can do whatever they want, you've pretty much
finished your job.
The missing parts are advanced stuff like new XInput and multi-touch support, but we were blocked by XCB for those, and users seem to be able to live without them. Now, since everyone seems really happy with the 3.4 branch, I think it's enough that we just keep maintaining it.
Although one could say awesome is finished now, there's an active community of users and the wiki is a goldmine for resources, including some user configuration files, themes, user-contributed widgets, and example screenshots. Awesome is available in the repositories of a lot of Linux distributions (but surprisingly not in Fedora), and also in the BSDs. Some of these distributions have their own wiki pages with a guide and distro-specific information, such as Arch Linux and Gentoo.
Tune it now
Although awesome is not an easy program to learn, the framework window manager invites you to experiment with and tune your desktop environment. For instance, you can modify your rc.lua file and restart awesome for these changes to have effect with a simple Win+Ctrl+r. To get some idea of the possibilities, have a look at all the signals awesome emits, to which you can hook your own handler functions. If you dislike the way how GNOME, KDE, and Unity are evolving and you want a window manager that you can tune to get out of your way, you definitely should take a look at awesome. For a quick glance, try the new Sabayon 7 Awesome edition.
Comments (52 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Distribution security response; New vulnerabilities in lightdm, Mozilla products, proftpd, wireshark, ...
- Kernel: Huge pages, slow drives, and long delays; Reverting disk aliases?; Reworking the DMA mapping code.
- Distributions: Fuduntu: A small distribution making it big; Android, Mandriva, openSUSE, ...
- Development: Raw photo manipulation with Darktable; IMAPclient, SciPy, Valgrind, ...
- Announcements: AVM vs. Cybits, W3C privacy workgroup, EFF on Internet innovation, ColorHug...