LWN.net Logo

LWN.net Weekly Edition for June 4, 2009

Okular, Debian, and copy restrictions

By Jonathan Corbet
June 1, 2009
One of the biggest advantages of free software is that it is usually written with the needs of its users in mind. Proprietary software, instead, has more of a tendency to reflect the interests of its owners. Thus, free applications do not normally implement "features" which allow their users to do less. One might think that the consensus against "antifeatures" in free software is nearly universal, but, as the case of the okular PDF reader in Debian shows, there are still exceptions.

The PDF file format includes a number of protection flags which specify whether the reader is allowed to print the file, make changes, or to copy out excerpts. There is nothing in the format which actively prevents such activities; these flags are simply instructions which any application operating on PDF files is expected to observe. If the "no copy" flag is set, cutting and pasting text from the file should - by the standard - be disabled in any reader application. Developers of free applications have, as a general rule, never quite gotten around to implementing this kind of restriction - even though the low-level poppler PDF-processing library makes such support possible. Applications which do implement this "feature" tend to disable it by default.

[Okular] This is not the case with Okular, though. An attempt to select text from a suitably-marked PDF file yields a rather confusing dialog which reads "copy forbidden by DRM" (see the image to the right). Amusingly, the application will still allow the selected region to be saved as an image file, but sending the text to the clipboard is not allowed. There is a configuration option which disables this behavior, but the default setting is to enforce the copy restriction flag.

John Goerzen encountered this behavior in Debian's Okular package; suffice to say he was not pleased. He filed a bug and asked:

So what I want to know is: why are people putting code into Debian that limits our freedom? Why are people putting such code into KDE?

And can we please patch it to stop that?

One of the important roles played by distributors is to serve as an intermediary between upstream projects and their users. If a development project does something which is not in the interests of its users, distributors have the opportunity, thanks to free licensing, to fix the problem. A look at a typical distributor's source packages will reveal that a number of applications have been patched in ways which change their behavior and generally make them fit in better. This final bit of finish is part of the value that distributors add.

Given that it's hard to find users who are asking for copy restriction features, one might think that this would be an ideal place for the Debian developers in charge of Okular to provide a more friendly default. But they do not want to do that. Okular developer Pino Toscano justifies the copy-restriction antifeature by saying that it's part of the PDF format specification. Since Okular is meant to follow the standard, it must do so in this case as well. Beyond that, Pino says:

If tomorrow a corporate person complains that Okular does not respect the PDF format in that sense and that they cannot make use of it because of that, what should I tell them? They would be right. Look, having the "power of developers" does not imply developers should feel like crackers, disabling restrictions just because they can or in the name of some "freedom".

Additionally, Debian KDE maintainer Sune Vuorela claims that the overhead of maintaining a patch to Okular would exceed the value gained - though it has been pointed out that the patch is trivial - and that the real problem is that people are downloading PDF files with restrictions in the first place. He states that Okular should not help users to "violate the conditions of use" associated with the file, but does not say why, if that is a concern, the ability to ignore copy restrictions is not patched out altogether.

Beyond that, others have raised concerns that failure to enforce copy restrictions could lead to legal problems in some jurisdictions. It is not clear which jurisdictions those would be, though. The copying of excerpts is allowed by fair use rules almost everywhere. Even the DMCA should not come into play here; the "do not copy" flag is simply a piece of advice found in the file which does not constitute an "effective technological measure" in any way. There has been a distinct shortage of legal problems (or even threats) associated with any of the other PDF readers which fail to implement this particular behavior. And, if such threats did exist, the existence of an option to ignore copy restrictions would be problematic regardless of its default value.

The evince PDF reader ran into this issue back in 2005. It is now rare to find a distributor shipping a version of evince which implements copy restrictions. Xpdf implements copy restrictions unconditionally, but Debian patched that code out in 2002, and that patch has spread to other distributors as well. In general, as one would expect, free PDF readers tend not to implement this behavior. Okular is about the only exception that your editor can find; it's interesting to note that the version of Okular shipped with Fedora Rawhide also implements copy restrictions by default. Perhaps this behavior is result of the relative newness of this application; as it accumulates more users, the pressure for more user-friendly behavior is likely to grow.

As that pressure mounts, Okular's developers and packagers may find it hard to justify keeping copy restrictions in place. Linux, at all levels, has felt free to ignore standards when following them makes no sense. And one could argue that the copy-restriction flag - which interferes with fair-use rights while doing nothing to prevent copying of the file or its contents - makes little sense indeed. This is not a feature which adds value for Linux users; such features still tend to disappear over time.

Comments (224 posted)

A look at two new languages: Vala and Clojure

June 3, 2009

This article was contributed by Nathan Willis

Some programming languages forge new ground, others are refinements of previously existing ideas, and still others tackle a specific problem in a new and better way. This article will look at two up-and-coming languages that are not yet as widely adopted as C, C++, or Java, but offer developers some intriguing benefits: Vala and Clojure. Vala is designed specifically to build native applications for the GNOME desktop environment, and Clojure brings the power of Lisp and functional programming to the Java Virtual Machine (JVM).

Vala

GNOME itself is written in C, but many of the higher-level libraries that make up the GNOME platform (such as GTK+ and Pango) make heavy use of the GLib and GObject frameworks, which implement a complete object system including types, messaging, classes, and all of the other components that make up a typical object oriented application program interface (API). GObject makes it possible to write object oriented GNOME applications in C, and also makes it simple to provide wrappers to GNOME for object oriented languages like C++ or Python.

While GObject makes object-oriented programming in C possible, it remains somewhat cumbersome. The GObject wrappers for other languages can be even worse, introducing yet another layer of dependencies which can include virtual machines of their own. Vala was created in an attempt to address these problems and make GNOME programming easier. Vala provides a C#-like syntax that integrates GObject features, but the valac compiler compiles to C output rather than assembly. The resulting C compiles normally with gcc, plus it can be distributed as source packages fully usable on platforms that do not have Vala installed. That allows the developer to use Vala's modern language features — dynamic type system, assisted memory management, and so on — while still making source releases compatible with C applications and libraries.

In addition to GLib and GObject, the Vala project produces bindings to the major GNOME libraries: GTK+, GDK, Cairo, SDL, GStreamer, D-Bus, GIO, and many more. In addition, several external projects provide their own bindings for Vala (such as Clutter), and there are third-party efforts to create bindings for other libraries, such as OpenGL. Plugins for Vala support are available for the Eclipse, Anjuta, and MonoDevelop IDEs, as well as for the editors Emacs, Vim, and GEdit. Val(a)IDE, still in development, is a dedicated Vala IDE written in Vala itself.

The latest release of Vala is 0.7.3, which went public on May 26, 2009. It is a bugfix release for the 0.7 series, which is intended to be the last development series before 1.0. The biggest change in the 0.7 series, according to developer Jürg Billeter, is to C header file generation. In previous releases, Vala would generate a .h header file for every .vala source file, which caused problems:

This caused various issues when the dependencies between the .vala source files get complex or more specifically, circular, and it did not allow us to have internal methods that can be used in multiple .vala files but remain outside the public API. Therefore we decided to move to a single public C header file with 0.7 and stop using separate header files for internal methods.

That change demanded making changes to the build system for existing Vala applications, but Billeter said it should be the last such headache for a while.

Vala 1.0 is scheduled to be released in September of 2009, coinciding with the release of GNOME 2.28. According to Billeter, the project is on track to make the 1.0 deadline, which will mark the start of a long stable release cycle during which application developers can count on language stability. The bindings to GNOME libraries are maintained separately, Billeter said, and are added to and enhanced on an as-needed basis, so they are not subject to the same schedule.

The project offers a tutorial and sample code for those new to Vala; some familiarity with GObject is expected. Benchmarks between Vala and C show no significant execution speed losses (in some cases, Vala even beats plain C).

The project maintains a list of applications developed using Vala, in whole or in part, including GNOME panel applets and full-fledged applications. The webcam utility Cheese is currently maintaining a Vala branch in addition to its main trunk, just to road test the viability of the language. Billeter noted that although people generally think of using Vala only when starting a new project, it is possible to incorporate it into an existing C code base, too. "Among our users are both, people writing C that now want to move to something higher level and also people that just start programming in the GNOME environment," he said.

Clojure

While Vala is a language designed around a particular object system, targeting a particular desktop environment, Clojure could not be more different. It is a dialect of the functional-flavored programming language Lisp, implemented on the Java platform. That makes it cross-platform; Clojure applications are compiled to Java bytecode, so they can run on any platform with a well-supported JVM.

Creator Rich Hickey has explained that building on top of the JVM grants Clojure automatic platform stability from a broad user and developer community, but that itself was not the goal of creating the language. Hickey's primary interest was concurrency — he wanted the ability to write multi-threaded applications, but increasingly found the mutable, stateful paradigm of object oriented programming to be part of the problem. "Discovering Common Lisp after over a decade of C++, I said to myself — 'What have I been doing with my life?', and resolved to at some point code in Lisp. Several years of trying to make that practical, with 'bridges' like jFli, Foil etc, made it clear that bridges weren't going to be sufficient for the commercial work I was doing."

Hickey became less enamored of object oriented programming and started adopting a functional-programming style in his work, which he found to make the code more robust and easier for him and for his coworkers to understand. Eventually, maintaining that style in other languages like C# became more trouble than it was worth:

The idea of a functional Lisp integrated with a commercially accepted host platform just seemed like chocolate and peanut butter. It can be hard to remember the exact time in which you decide to do the crazy thing that is designing a new language - you just find yourself doing it because you have to. Coming up with persistent data structures that were fast enough was the tipping point for my considering it viable.

Clojure does provide persistent data structures, although it does considerably more. For those unfamiliar, functional programming (the style from which Lisp and Clojure originate) places a greater emphasis on functions as first-class objects, meaning that functions can be placed into data structures, passed as arguments to other functions, evaluated in comparisons, even returned as the return value of another function. Moreover, functions do not have "side effects" — the ability to modify program state or data. This paradigm focuses on computation in the mathematical sense, rather than procedural algorithms, and is a completely different approach to programming.

As a language, Clojure is a Lisp-1, part of the same family of Lisp variants as Scheme, notable for sharing a single namespace between functions and variables. Clojure differs from Scheme and other Lisp dialects in several respects documented at the Clojure web site. For application developers, the most significant distinction is that Clojure defaults to making all data structures immutable. To maintain program state, developers must use one of four special mutable structures that are explicitly designed to be shared between threads: refs, vars, atoms, and agents. Clojure uses software transactional memory (STM) to coordinate changing these mutable structures while keeping them in a consistent state, much like a transactional database. This model makes it considerably simpler to write thread-safe code than it is in object oriented languages. No locks are required, therefore there are no deadlocks or race conditions.

Like other Lisp implementations, Clojure is interpreted through a console-like read-eval-print-loop (REPL). The user launches the REPL from a .jar file and is presented with the REPL command prompt, from which he or she can load Clojure programs or directly write and execute functions and macros. The code is compiled on-the-fly to Java bytecode, which is then in turn executed by the JVM. The REPL environment is much like an interactive IDE and debugger all rolled into one, but for distribution purposes, Clojure code can be compiled ahead of time into ordinary Java applications. Because it is hosted by the JVM, Clojure can automatically make use of its features, including the type system, thread implementation, and garbage collector, rather than having to re-implement each of them. Clojure code can also call Java libraries, opening up a wealth of classes and interfaces to Clojure programmers.

Clojure 1.0 was released on May 4, 2009. There are several good resources online for learning about the language and for getting started, although a general introduction to Lisp is probably warranted for those with no experience in functional programming. Though there are not large-scale projects using Clojure, an active community is growing around it, including several local users' groups. The Clojure site offers documentation of the language syntax and examples (including example code), there is a very active Google Groups discussion forum, and Mark Volkmann's Clojure page at Object Computing tracks articles, slides, and wikibooks about Clojure.

Two-way interoperability

Vala and Clojure seem to have little if anything in common; one is object oriented and the other functional, one aimed at a specific desktop system and the other intentionally cross-platform. They are kindred spirits in one sense, however — they seek to build a more modern, robust language implementation on top of an existing, established platform. Vala's goal is to let C programmers more easily take advantage of the power of GObject and GNOME, and Clojure's is to let developers easily write concurrent applications on top of the stability of the JVM.

What is equally important is that both projects maintain bi-directional compatibility with their underlying languages and platforms. A Vala program can use any C library, and a C program can use any library written in Vala. Likewise, Clojure code can be compiled to Java, and Clojure applications can use any Java class or interface. Such interoperability will likely increase adoption of both of these languages, and it is a welcome sight in any project.

Comments (39 posted)

Waiting for Google Chrome

June 3, 2009

This article was contributed by Bruce Byfield

When Google Chrome was released for Windows on September 2, 2008, it attracted instant attention. With increased speed, security, and stability, Chrome seemed every bit the modern rethinking of the web browser that Google proclaimed it. But despite the fact that Chrome is an open source project with different portions of it released under a variety of free licenses, the GNU/Linux version is still in early development. However, the recent availability of regular builds in Ubuntu packages promises to make casual experimentation with Chrome much easier, and revived the original interest. Unfortunately, the current state of the GNU/Linux version seems unlikely to satisfy the level of interest, as the development team continues to struggle with unexpected challenges.

Asked how many people were part of Chromium, the Google team that is building Chrome, and how many were working on the GNU/Linux version specifically, Mike Smith, Product Manager for Google Chrome, declined to give numbers. "We don't go into details about the number of Google employees on any particular product," he explained. However, an unofficial list of those working on Chrome in September 2008 included 42 names, 3 of whom had Linux listed as an area of expertise. This number, which has probably changed in the last nine months, is supplemented by several developers with experience in writing cross-platform applications, including Firefox alumnae Darin Fisher, Pam Greene, and Ben Goodger, Chrome's technical lead. In addition, the Chromium tasks in the 2009 Summer of Code include nine possible GNU/Linux-related improvements that students might undertake.

Another reason that the numbers are fuzzy, Smith pointed out, is that Chromium works closely with other Google teams, including Gears, a plug-in that enhances both online and offline performance of web applications; Native Client, whose goal is to allow traditional applications to run as web applications; and O3D, which seeks to add 3-D capabilities to web applications. When such considerations are taken into account, it seems that, while the Windows version seems to have highest priority, since it was released first, the GNU/Linux one is still far from being neglected.

The challenges of designing for GNU/Linux

So far as possible, the code for the GNU/Linux, Mac, and Windows versions of Chrome "share as much as is possible — not only in terms of core aspects share with other source projects, such as with the Webkit team, but also from UI [User Interface] design choices and other implementation aspects of the technology," Smith said. However, as the Ars Technica highlighted in a review of a pre-alpha release, the sheer variety of options under GNU/Linux can often prove a challenge.

For example, Smith mentions the difficulties of implementing sandboxing — the running of applications in restricted environments as a security precaution:

On Windows, getting a process sandboxed in a way that's useful to us is pretty complicated — the relevant source code consists of over 100 files and is located under the sandbox directory in Chromium's Open Source repository. But on Linux there are a number of different sandboxing mechanisms available. Different Linux distributions ship with different (or no) sandboxing APIs, and finding a mechanism that is guaranteed to work on end-user's machines is a challenge.

The issues include whether to use ftrace or a modified version of Seccomp to intercept system calls for sandboxing, and whether system call interception is necessarily the best mechanism for sandboxing.

Other challenges in GNU/Linux include the lack of a standard developer's toolkit, the variety of software available for the same purpose, and the limitations of the GTK+ toolkit. In the Ars Technica review, the frustrations with these limits were attributed to Goodger alone. But if you look at the original discussion thread, working around the conditions in GNU/Linux are a challenge for all the Chromium developers. At the very least, the team felt the need for common standards to simplify their work.

Goodger explained:

Google Chrome's visual style was designed with the assumption that the window manager is a stable target. On Windows and Mac, we have used this assumption to allow the tabs to blend seamlessly into the window title bar, creating Google Chrome's distinctive skyline. We also use the dominant system theme (the blue Luna theme on Windows XP, Aero Glass on Windows Vista, and the standard grey appearance on OS x) to inform the general appearance.

Building an application with these objectives in mind is much more challenging on Linux because of the lack of general consensus as to what the default user interface toolkit, theme system, and window managers are. Because of how extensively the system can be customized and how frequently this is actually done by a large number of Linux users, many of the assumptions that drove the design of Chrome's UI are more challenging to apply. That said, the Linux team has some clever ideas for how they may be able to support the best of both worlds, and so I look forward to these being implemented.

At least part of the time, the solutions that emerged were a compromise or stopgap measure. For example, despite the team's reservations about the ability of GTK+ to produce an interface comparable to those on Windows or OSX, Smith says that "In the end, we decided that GTK+ gave the best compromise in terms of being able to deliver a quick, clean user experience that was clearly still Google Chrome."

In much the same way, Smith described the release of nightly builds for Ubuntu as being due to the fact "that we have to start somewhere," even though the plans are to support "multiple popular distributions." He added that, "Being open source means we're happy to have volunteers provide support for other, potentially less popular or more specific distros that we may not get around to for a while."

Looking ahead

The Chromium team declined to give an exact road map for the GNU/Linux version. However, Smith did say that "We hope to release a version of Google Chrome for Linux on the developer channel very soon." Those who are interested in tracking Chrome's progress can track it on the developer site.

Still to come are an extensions platform intended to give Chrome the rich ecosystem of development enjoyed by Firefox. Smith also suggested that Chrome's ability to quickly render JavaScript should make it ideal for the recently announced Google Wave, an online collaboration and communication system. "We certainly expect Wave to work best in modern browser environments which have good support for open web standards," Smith said.

Meanwhile those wanting to investigate Google Chrome on their own can download packages from Ubuntu's Launchpad site, which include packages for the last three Ubuntu releases as well as the upcoming Karmic Koala release. However, if you do, be warned that, at this stage of development, there is no guarantee that you will actually be able to run Chrome. On three separate machines with several different builds and packages, I was able to install the browser, but received only an "Illegal instruction" message when attempting to run it.

Such failures are not surprising in software in such an early stage of development. No doubt, too, the particular hardware and builds figure heavily in them. All the same, they suggest that the Google could be hard-pressed to deliver on its promise of a GNU/Linux release in the first half of this year. At the most, an early beta might be ready by that deadline.

Meanwhile, users can keep trying the Ubuntu packages. They might also try compiling the source code, or downloading Crossover Chromium, which runs under the WINE code. The only other alternative is to wait for the still-indefinite final release.

Comments (13 posted)

Page editor: Jonathan Corbet

Security

Google's Native Client

By Jake Edge
June 3, 2009

Allowing browsers to run native code downloaded from a web site has some attractions, at least at first blush. But, once some thought is put into it—or the serious security problems with Microsoft's ActiveX are recalled—the security flaws of the scheme become readily apparent. Google is resurrecting the idea in their Native Client (NaCl) research project, but rather than rely on trust, as ActiveX does, NaCl takes steps to verify the code before running it. As a weblog posting by Matasano Security describes, there are rather substantial technical barriers to overcome, but, even then, there are still some fairly serious repercussions to running native code from an untrusted site.

The reasons that native code is so attractive are that it allows for much better performance along with access to graphics and a user interface that isn't HTTP-based. One of the NaCl demos is a port of Quake so that it can run in the browser. Certainly games are one place where NaCl is attractive, but, also, for any existing program—at least those that aren't written in Java, Flash, or Silverlight—porting it to a new language is not required. For those who think that essentially all applications will eventually be delivered by the web, NaCl (or something like it) seems required.

But, as malware developers know, the x86 architecture has lots of ways to obscure the operation of a program in order to try to elude any kind of automatic vetting. The instructions are of variable length and malicious programs can jump anywhere in the stream, not just at the instruction boundaries found by a disassembler. In addition, x86 programs can execute from data, so that malicious programs can write some code to memory and jump there. These kinds of things cannot be determined by just examining the program binary, so Google leveraged some earlier work [PDF] to restrict the kinds of programs NaCl will execute.

Basically, NaCl requires that the code be structured such that it can be verified automatically. That means that disassembling the code must produce a stream of recognizable instructions and that jumps must land at the beginning of one of those instructions. In addition, self-modifying code is disallowed. With those restrictions in place, NaCl can verify that the code doesn't do anything that is disallowed.

NaCl then enforces some additional rules, disallowing memory management hacks that could fool the verifier and requiring that all system calls go through a "gate" in the first 64K of the code. Only certain calls are allowed through the gate, which is how NaCl protects against arbitrary code being executed. Google has created a patched version of GCC that will create an ELF-format file which follows the rules.

All of that may sound enticing, but Matasano puts a definite damper on enthusiasm for the technique. In some ways, it is similar to what Java applet sandboxes do, but Java has been around for quite some time, so many of the problems with its implementation have been found and fixed. Google sponsored a contest to try to shake out some of the problems with NaCl. Matasano participated and the blog post is essentially a report of what they and others found.

The basic problem is that bugs in the verifier, loader, or trusted system call gate can generally be immediately turned into exploits to run arbitrary code. The posting outlines a number of problems that they or other contest teams found. Until the NaCl components reach a level of maturity similar to—or even beyond—that of the Java applet sandbox, running native code in the browser is going to be a dicey proposition. A particular area of concern is that the system call gate must do its job based on what call is being made and the contents of the memory being passed, which is a much harder job than the equivalent for the Java sandbox (which is expressed in terms of Java classes and data structures).

But, even if all of the bugs with NaCl itself were found and fixed—an impossible task—there is still an architectural hole that was specifically removed from consideration in the contest: side-channel attacks. There are a number of attacks against keys and other sensitive information that can be made using timing analysis. By timing repeated executions of the code of interest, cache effects as well as branch prediction information can be extracted, which can then be used to recover keys or other information.

While the side-channel attacks are probabilistic in nature, they get better with repetition. If an attacker were able to add that kind of analysis as part of a popular game, for example, it would have ample opportunity to run. Since the kind of abilities required by the side-channel program are not very different than other, legitimate programs that NaCl would want to run, there is little that can be done to stop this kind of abuse. Whether it is a practical attack is hard to judge, but undoubtedly some attackers are already looking at it.

It seems likely that any security-conscious user is not going to be too interested in running code in NaCl anytime soon—if ever. Unfortunately, the same folks who are willing to run ActiveX programs from random internet sites might be quite willing to do the same with NaCl. That could lead to an ugly security breach of some kind, but one could argue that it is not really any worse than things are today. Running untrusted code is dangerous and there aren't many ways around that.

Comments (24 posted)

New vulnerabilities

cups: denial of service

Package(s):cups, cupsys CVE #(s):CVE-2009-0949
Created:June 3, 2009 Updated:December 8, 2009
Description: The CUPS IPP code contains a null-pointer dereferencing bug. An attacker can exploit this flaw to crash the server, leading to a denial of service.
Alerts:
Mandriva MDVSA-2009:282-1 2009-12-07
Mandriva MDVSA-2009:282 2009-10-19
Mandriva MDVSA-2009:283 2009-10-19
Mandriva MDVSA-2009:281 2009-10-19
SuSE SUSE-SR:2009:012 2009-07-03
CentOS CESA-2009:1082 2009-06-10
CentOS CESA-2009:1083 2009-06-03
Red Hat RHSA-2009:1082-01 2009-06-03
Red Hat RHSA-2009:1083-01 2009-06-03
Ubuntu USN-780-1 2009-06-03

Comments (none posted)

drupal6: cross-site scripting

Package(s):drupal6 CVE #(s):
Created:June 1, 2009 Updated:June 3, 2009
Description:

From the Debian advisory:

Markus Petrux discovered a cross-site scripting vulnerability in the taxonomy module of drupal6, a fully-featured content management framework. It is also possible that certain browsers using the UTF-7 encoding are vulnerable to a different cross-site scripting vulnerability.

Alerts:
Debian DSA-1808-1 2009-06-01

Comments (none posted)

eggdrop: remote denial of service

Package(s):eggdrop CVE #(s):CVE-2009-1789
Created:June 2, 2009 Updated:December 8, 2009
Description: From the Mandriva advisory: mod/server.mod/servmsg.c in Eggheads Eggdrop and Windrop 1.6.19 and earlier allows remote attackers to cause a denial of service (crash) via a crafted PRIVMSG that causes an empty string to trigger a negative string length copy.
Alerts:
Mandriva MDVSA-2009:126-1 2009-12-08
Debian DSA-1826-1 2009-07-04
Mandriva MDVSA-2009:126 2009-06-01

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):linux-2.6 CVE #(s):CVE-2009-1630 CVE-2009-1633 CVE-2009-1758
Created:June 2, 2009 Updated:February 15, 2010
Description: From the Debian advisory:

Frank Filz discovered that local users may be able to execute files without execute permission when accessed via an nfs4 mount. CVE-2009-1630

Jeff Layton and Suresh Jayaraman fixed several buffer overflows in the CIFS filesystem which allow remote servers to cause memory corruption. CVE-2009-1633

Jan Beulich discovered an issue in Xen where local guest users may cause a denial of service (oops). CVE-2009-1758

Alerts:
SuSE SUSE-SA:2010:012 2010-02-15
SuSE SUSE-SA:2009:045 2009-08-20
Debian DSA-1865-1 2009-08-16
Red Hat RHSA-2009:1211-01 2009-08-13
Debian DSA-1844-1 2009-07-28
SuSE SUSE-SA:2009:056 2009-11-16
SuSE SUSE-SA:2009:054 2009-11-11
rPath rPSA-2009-0111-1 2009-07-24
SuSE SUSE-SA:2009:038 2009-07-23
Red Hat RHSA-2009:1157-01 2009-07-14
Mandriva MDVSA-2009:148 2009-07-07
Ubuntu USN-793-1 2009-07-02
Red Hat RHSA-2009:1132-01 2009-06-30
CentOS CESA-2009:1106 2009-06-19
Mandriva MDVSA-2009:135 2009-06-17
Red Hat RHSA-2009:1106-01 2009-06-16
SuSE SUSE-SA:2009:031 2009-06-09
Debian DSA-1809-1 2009-06-01

Comments (none posted)

libsndfile: arbitrary code execution

Package(s):libsndfile CVE #(s):CVE-2009-1788 CVE-2009-1791
Created:May 28, 2009 Updated:December 4, 2009
Description: libsndfile has a pair of arbitrary code execution vulnerabilities. From the Gentoo alert:

Tobias Klein reported that the header_read() function in src/common.c uses user input for calculating a buffer size, possibly leading to a heap-based buffer overflow (CVE-2009-1788).

The vendor reported a boundary error in the aiff_read_header() function in src/aiff.c, possibly leading to a heap-based buffer overflow (CVE-2009-1791).

Alerts:
Mandriva MDVSA-2009:132-1 2009-12-03
Fedora FEDORA-2009-11618 2009-11-16
Fedora FEDORA-2009-11499 2009-11-16
SuSE SUSE-SR:2009:013 2009-08-11
Ubuntu USN-849-1 2009-10-15
Debian DSA-1814-1 2009-06-13
Mandriva MDVSA-2009:132 2009-06-07
Gentoo 200905-09 2009-05-27

Comments (none posted)

ocsinventory: SQL injection

Package(s):ocsinventory CVE #(s):CVE-2009-1769
Created:June 2, 2009 Updated:June 3, 2009
Description: From the Fedora advisory: OCS Inventory NG: Authentication result varies for existent and non-existent users - SQL injection and Unauthenticated Arbitrary File Read.
Alerts:
Fedora FEDORA-2009-5769 2009-06-02
Fedora FEDORA-2009-5773 2009-06-02
Fedora FEDORA-2009-5764 2009-06-02

Comments (none posted)

opensc: information disclosure

Package(s):opensc CVE #(s):CVE-2009-1603
Created:May 28, 2009 Updated:August 3, 2009
Description: opensc has an information disclosure vulnerability. From the Mandriva alert: src/tools/pkcs11-tool.c in pkcs11-tool in OpenSC 0.11.7, when used with unspecified third-party PKCS#11 modules, generates RSA keys with incorrect public exponents, which allows attackers to read the cleartext form of messages that were intended to be encrypted (CVE-2009-1603).
Alerts:
Gentoo 200908-01 2009-08-01
Fedora FEDORA-2009-4967 2009-05-14
Fedora FEDORA-2009-4928 2009-05-14
Mandriva MDVSA-2009:123 2009-05-27

Comments (none posted)

opensc: insecure key generation

Package(s):opensc CVE #(s):CVE-2009-0368 CVE-2008-2235
Created:June 1, 2009 Updated:August 3, 2009
Description:

From a message on the OpenSC mailing list:

The security problem in short: you need a combination of

1.) a tool that starts a key generation with public exponent set to 1 (an invalid value that causes an insecure rsa key)

2.) a PKCS#11 module that accepts that this public exponent and forwards it to the card

3.) a card that accepts the public exponent and generates the rsa key.

OpenSC is insecure because due to a code bug in pkcs11-tool it had the wrong public exponent. But OpenSC PKCS#11 module is secure, it ignores the public exponent. So only if you generate your keys with pkcs11-tool from OpenSC 0.11.7 (which very few people do), and only if you used it with some other vendors PKCS#11 module, and only if the card accepted the bogus value too, then your rsa key is insecure.

Alerts:
Gentoo 200908-01 2009-08-01
Fedora FEDORA-2009-4892 2009-05-12
Fedora FEDORA-2009-4919 2009-05-12
Fedora FEDORA-2009-4883 2009-05-12

Comments (none posted)

php-smarty: arbitrary command execution

Package(s):php-Smarty CVE #(s):CVE-2009-1669
Created:May 28, 2009 Updated:August 18, 2010
Description: php-smarty has an arbitrary command execution vulnerability. From the Red Hat bug entry: The smarty_function_math function in libs/plugins/function.math.php in Smarty 2.6.22 allows context-dependent attackers to execute arbitrary commands via shell metacharacters in the equation attribute of the math function. NOTE: some of these details are obtained from third party information.
Alerts:
Debian DSA-1919-2 2010-08-17
Gentoo 201006-13 2010-06-02
Debian DSA-1919-1 2009-10-25
Ubuntu USN-791-3 2009-06-24
Ubuntu USN-791-1 2009-06-24
Fedora FEDORA-2009-5520 2009-05-27
Fedora FEDORA-2009-5525 2009-05-27

Comments (none posted)

tshark: denial of service

Package(s):tshark CVE #(s):
Created:May 28, 2009 Updated:June 3, 2009
Description: tshark has a denial of service vulnerability. From the rPath alert: Previous versions of wireshark contain a Denial of Service vulnerability in the PCNFSD dissector. This vulnerability has been corrected.
Alerts:
rPath rPSA-2009-0095-1 2009-05-27

Comments (none posted)

wireshark: unspecified denial of service

Package(s):wireshark CVE #(s):CVE-2009-1829
Created:June 1, 2009 Updated:June 30, 2009
Description:

From the Mandriva advisory:

Unspecified vulnerability in the PCNFSD dissector in Wireshark 0.8.20 through 1.0.7 allows remote attackers to cause a denial of service (crash) via crafted PCNFSD packets (CVE-2009-1829)

Alerts:
Gentoo 200906-05 2009-06-30
CentOS CESA-2009:1100 2009-06-16
Red Hat RHSA-2009:1100-01 2009-06-15
Mandriva MDVSA-2009:125 2009-05-31

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The current development kernel is 2.6.30-rc8, released on June 2. It is probably the last prepatch before the final 2.6.30 release. "A lot of small stuff, fixing a few regressions (and at least one bugzilla entry going back to 2.6.24). The small stuff does matter. Please test." Full details can be found in the long-format changelog.

There have been no stable releases over the last week; the last stable update was 2.6.29.4 on May 19.

Comments (none posted)

Kernel development news

Quotes of the week

fyi, the above discussion transitions akpm into the "confused" state. I'll keep the patch on hold until akpm transitions back out of that state.
-- Andrew "akpm" Morton

Because, when you think about it, there's really no merit in having consistently wrong code. A mix of right and wrong is better than 100% wrong.
-- Andrew Morton

The Dom0 push of Xen just seems too much like Linux being Xen's sex slave, when it should be the other way around.
-- Steven Rostedt

Comments (none posted)

In brief

By Jonathan Corbet
June 3, 2009

Retrying core dump writes: Paul Smith posted a patch that would retry short or interrupted writes while dumping core, thus preventing the creation of an incomplete core dump when a signal arrives. Alan Cox NAK-ed the patch noting: "The existing behaviour is an absolute godsend when you've something like a core dump stuck on an NFS mount or something trying to core dump to very slow media." But the idea did lead to some interesting discussion of which signals should cause a core dump to be interrupted—thus leaving a short core file—and which should be ignored.

There is an inherent difference between some interactive program that is dumping core which a user might wish to interrupt with SIGINT versus a non-interactive process which the user or developer might wish to finish its core dump. Smith describes one scenario: "a worker process might appear unresponsive due to a core being dumped and the parent would decide to shoot it with SIGINT based on various timeouts etc." No decision was made, but Roland McGrath analyzed four signal categories and noted that at least two of the categories needed to be addressed as they are mishandled by the current code.

Device tree. The Open Firmware "device tree" is a description of a system's hardware configuration in a standardized data structure. Some platforms have used device trees to separate the description of the hardware from the kernel running on that hardware; that, in turn, allows one kernel to support a wider variety of systems. Janboe Ye recently proposed adding device tree support to the ARM architecture, which arguably supports the widest variety of hardware of all. That has, in turn, led to a long discussion of how much device tree really helps, and how feasible it is to create a single kernel for all systems of a given architecture.

Developers of architectures using device tree seem to be happy with the results; see this 2008 OLS paper [PDF] for a description of how things went with the PowerPC architecture. Maintainers of other architectures are less convinced, though. ARM maintainer Russell King worries that device tree could turn out to be an expensive dead end; he would like to see a subset of ARM architectures converted first to find out whether it is likely to work well or not. An incremental approach probably makes sense in general, so that's how things are likely to go.

The "host protected area" is an IDE concept which allows a controller to hide a portion of a drive from the operating system's view. When HPA was introduced years ago, its primary use was to make large drives (by the standards of the day) appear small so that certain legacy operating systems would not be confused. Linux, naturally, never had any such problem, so the Linux IDE layer would traditionally disable the HPA during the probing process. That was the right thing to do at the time; it allowed Linux systems to make use of the entire drive.

It has been a while since operating systems required protection from the shock of seeing an overly-large drive. But the HPA remains for different reasons. Vendors will use the HPA to stash RAID information, for example. Windows systems often come with a full "reinstall this system from the beginning" recovery image - apparently a useful feature on that platform. Rootkits sometimes hide information there. And so on. In all cases but the last, it is probably a mistake for the operating system to overwrite the HPA on contemporary systems. So turning off HPA protection by default is no longer the right thing to do.

The libata driver subsystem has observed the HPA since the beginning, but the IDE code retains its old default. That could change, though, with a patch set posted by IDE maintainer Bartlomiej Zolnierkiewicz. These patches will cause the IDE layer to preserve the HPA by default - unless the drive has partitions which cover the HPA already. That test should be enough to ensure that older systems continue to function while avoiding trashing the HPA on newer drives. For systems not properly covered by this change, the nohpa module parameter can be used to control HPA behavior directly.

reflink(). There's another reflink() proposal out there. This one simplifies the preserve argument slightly, replacing the set of flags with an all-or-none option for now. So reflink() can be used in the full snapshot mode (with suitable privilege) or in the reflink-as-copy mode, but with no options in between.

Control over process IDs. The proposed checkpoint/restart feature has a number of challenges to overcome. One of those is that processes can become very confused if their process ID changes suddenly. So restarting a checkpointed process requires that the process's old ID be restored as well. The use of PID namespaces can help to ensure that the requisite IDs are available, but there's no way in Linux to request that a process be started with a specific ID.

Sukadev Bhattiprolu has a proposal for a new system call to address this problem: clone_with_pids(). It would behave like ordinary clone(), but it takes an additional argument being an array of process IDs. The array contains one desired process ID for each namespace in the current hierarchy, with the first being the global namespace. Deeply-nested processes can, thus, be created with a specific ID in each namespace where it will appear.

This patch has been "gently tested" and not posted outside of the containers list, so it has seen relatively little review thus far. Expect some changes if this code starts to get closer to the mainline.

Comments (5 posted)

How many page flags do we really have?

By Jonathan Corbet
June 3, 2009
The recently-discussed kernel memory sanitization patch was criticized on a number of points, one of which was its use of a dedicated page flag. Andi Kleen's HWPOISON patch (enabling upcoming Intel CPU features for dealing with memory errors) have run into trouble on similar grounds. The desperate shortage of page flags has been an article of faith among kernel developers for years. But, interestingly, not everybody agrees that a problem exists, and almost nobody can answer the simple question of how many flags are available in the first place. So a look at the Linux page flags issue seems in order.

"Page flags" are simple bit flags describing the state of a page of physical memory. They are defined in <linux/page-flags.h>. Flags exist to mark "reserved" pages (kernel memory, I/O memory, or simply nonexistent), locked pages, those under writeback I/O, those which are part of a compound page, pages managed by the slab allocator, and more. Depending on the target architecture and kernel configuration options selected, there can be as many as 24 individual flags defined.

These flags live in the flags field of struct page. This field is declared to be an unsigned long, so one might think that figuring out how much space is left for new flags would be a straightforward task. To a casual observer, it would look like, on a 32-bit system, 24 flags have been used, leaving eight available:

[Page
flags]
In other words, the situation is starting to get tight, but it is not a crisis quite yet.

But little is straightforward when it comes to struct page. One of these structures exists for every physical page in the system; on a 4GB system, there will be one million page structures. Given that every byte added to struct page is amplified a million times, it is not surprising that there is a strong motivation to avoid growing this structure at any cost. So struct page contains no less than three unions and is surrounded by complicated rules describing which fields are valid at which times. Changes to how this structure is accessed must be made with great care.

Unions are not the only technique used to shoehorn as much information as possible into this small structure. Non-uniform memory access (NUMA) systems need to track information on which node each page belongs to, and which zone within the node as well. Rather than add fields to struct page, the NUMA hackers grabbed the free bits at the top of the flags field, yielding something like this:

[Page
flags]

So, on a 32-bit system with 24 page flags defined (a pessimistic scenario), there are eight bits available for the node and zone information, practically limiting 32-bit NUMA systems to 64 nodes, which is almost certainly adequate. But the addition of more page flags would come at the cost of supporting fewer NUMA nodes, and that would be unwelcome.

Things get worse on systems with complicated physical memory layouts. On such systems, memory is not organized into a single, continuous range of physical addresses; instead, it is spread out with holes in the middle. Memory management on these "sparse memory" systems requires that each page have a "section" number associated with it. That section number is stored - you guessed it - in the spare bits at the top of the flags field. If space gets too tight, the kernel will move the node number into a separate array, slowing things down in the process. Either way, it seems clear that there is not a whole lot of spare room in the flags field on these systems.

So the real answer to "how many page flags are free?" is, for all practical purposes, "zero," at least on 32-bit NUMA systems. Making room for more would require expanding struct page, which is a heavy cost to pay. Developers should, thus, not be surprised when proposals to use new page flags run into stiff opposition. It's only one bit, but that bit is in the middle of some of the most sought-after real estate in the entire kernel.

In the case of Andi's HWPOISON patch, this opposition has come in the form of a number of alternative suggestions. One was to simply use the "reserved" bit, but that could lead to difficulties in parts of the code where that usage is not expected. Then it was suggested that the combination of the "reserved" and "writeback" flags could indicate a poisoned page, but Andi claims that this approach cannot work. Andrew Morton has suggested that HWPOISON could be made into a 64-bit-only feature; Andi allows as to how that might be possible, but he clearly doesn't like the idea.

Instead, Andi takes the position that the page flag shortage does not really exist. It's not a problem at all on 64-bit systems, where unsigned long is twice as wide. The number of 32-bit systems with a large number of NUMA nodes is small and shrinking; it's not something that the developers need be concerned about. And, says Andi, if things get really bad, the sparse memory section number can be moved into a separate array like the NUMA node number. Given this view of the problem, worries about adding a useful new feature over concerns about a single page flag bit seem misplaced.

Nobody has challenged Andi's view that the problem is not as severe as most people think, though Andrew Morton has hinted that Andi should go ahead and prove his ideas about moving the section number out of the page structure. That might not be a bad idea. Even if page flags are a little more abundant than most developers think, it still is not hard to foresee a time when they are exhausted, at least on 32-bit systems. Proposals involving new page flags are not particularly rare; unless we want to restrict features needing page flags to 64-bit systems, we'll need to make some more flags available before too long.

Comments (7 posted)

Xen again

By Jonathan Corbet
June 3, 2009
Your editor is widely known for his invariably correct and infallible predictions. So, certainly, he would never have said something like this:

Mistakes may have been made in Xen's history, but it is a project which remains alive, and which has clear reasons to exist. Your editor predicts that the Dom0 code will find little opposition at the opening of the 2.6.30 merge window.

OK, anybody needing any further evidence of your editor's ability to foresee the future need only look at his investment portfolio...or, shall we say, the smoldering remains thereof. Needless to say, Xen Dom0 support did not get through the 2.6.30 merge window, and it's not looking very good for 2.6.31 either.

Dom0, remember, is the hypervisor portion of the Xen system; it's the One Ring which binds all the others. Unlike the DomU support (used for ordinary guests), Dom0 remains outside of the mainline kernel. So anybody who ships it must patch it in separately; for a patch as large and intrusive as Dom0, that is not a pleasant task. It is a necessary one, though; Xen has a lot of users. As expressed by Xen hacker Jeremy Fitzhardinge:

Xen is very widely used. There are at least 500k servers running Xen in commercial user sites (and untold numbers of smaller sites and personal users), running millions of virtual guest domains. If you browse the net at all widely, you're likely to be using a Xen-based server; all of Amazon runs on Xen, for example. Mozilla and Debian are hosted on Xen systems.

Xen developers and users would all like to see that code merged into the mainline. A number of otherwise uninvolved kernel developers have also argued in favor of merging this code. So one might well wonder why there is still opposition.

One problem is a fundamental disagreement with the Xen design, which calls for a separate user-space hypervisor component. To some developers, it looks like an unfortunate mishmash of code in the mainline kernel, in Xen-specific kernel code, and in user space - with, of course, a set-in-concrete user-space ABI in the middle. Many developers are more comfortable with the fully in-kernel hypervisor approach taken by KVM. Thomas Gleixner is especially worried about the possible results of merging the Xen Dom0 code for this reason (among several others):

Aside of that it can also hinder the development of a properly designed hypervisor in Linux: 'why bother with that new stuff, it might be cleaner and nicer, but we have this Xen dom0 stuff already?'.

Steven Rostedt, who has worked on Xen in the past, also dislikes the hypervisor design and the effects it has on kernel development:

The major difference between KVM and Xen is that KVM _is_ part of Linux. Xen is not. The reason that this matters is that if we need to make a change to the way Linux works we can simply make KVM handle the change. That is, you could think of it as Dom0 and the hypervisor would always be in sync.

If we were to break an interface with Dom0 for Xen then we would have a bunch of people crying foul about us breaking a defined API. One of Thomas's complaints (and a valid one) is that once Linux supports an external API it must always keep it compatible. This will hamper new development in Linux if the APIs are scattered throughout the kernel without much thought.

Steven suggests merging the Xen hypervisor into the mainline so that it's all part of Linux, and to make the hypervisor ABI an internal, changeable interface. Some other developers - generally those most hostile to merging Dom0 in its current form - supported this idea. It's certainly not the first time that this sort of idea has been raised. But, despite many calls to bring some of the "plumbing layer" into the kernel proper, that has yet to happen; it seems unlikely that something as large as Xen would be the first user-space component to break through that barrier - even if the Xen developers were amenable to that approach.

The hypervisor design would probably not be an insurmountable obstacle to merging by itself. But there are other complaints. The maintainers of the x86 architecture dislike the changes made to their code by the Dom0 patches. By their reckoning, there are far too many "if (xen)..." conditionals and too many #ifdefs. They would very much like to see the Xen code cleaned up and made less intrusive into the core x86 code. Linus supports them on this point:

The fact is (and this is a _fact_): Xen is a total mess from a development standpoint. I talked about this in private with Jeremy. Xen pollutes the architecture code in ways that NO OTHER subsystem does. And I have never EVER seen the Xen developers really acknowledge that and try to fix it.

The Xen cause was also not helped by some performance numbers posted by Ingo Molnar. If you choose the right benchmark, it seems, you can show that the paravirt_ops layer imposes a 1% overhead on kernel performance. Paravirt_ops is the code which abstracts low-level machine operations; it can enable the same kernel to run either on "bare metal" or virtualized under a hypervisor. It adds a layer of indirect function calls where, before, inline code was used. Those function calls come at a cost which has now been quantified by Ingo (but one should note that Rusty Russell has shown that, with the right benchmark, a number of other common configuration options have a much higher cost).

The problem here is not that Xen users have a slower kernel; the real issue is that any kernel which might ever be run under Xen must be built with paravirt_ops enabled. There are few things which make distributors' lives more miserable than forcing them to build, ship, and support another kernel configuration. So most distributor kernels run with paravirt_ops enabled; that means that all users, regardless of whether they have any interest in Xen, pay the price. In some cases, that cost is too high; Nick Piggin said:

FWIW, we had to disable paravirt in our default SLES11 kernel. (admittedly this was before some of the recent improvements were made). But there are only so many 1% performance regressions you can introduce before customers won't upgrade (or vendors won't publish benchmarks with the new software).

Ingo is strongly critical of the perceived cost of paravirt_ops, but he also proposes a solution:

Note what _is_ acceptable and what _is_ doable is to be a bit more inventive when dumping this optional, currently-high-overhead paravirt feature on us. My message to Xen folks is: use dynamic patching, fix your hypervisor and just use plain old-fashioned _restraint_ and common sense when engineering things, and for heaven's sake, _care_ about the native kernel's performance because in the long run it's your bread and butter too.

He goes on to say that merging Dom0 now would only make things worse; it would give the Xen developers less incentive to fix the problems while, simultaneously, making it harder for distributors to disable paravirt_ops in their kernels.

And that, perhaps, leads to the fundamental disconnect in this discussion. There are two distinctive lines of thought with regard to when code with known problems should be merged:

  • Some developers point out that code which is in the mainline benefits from the attention of a much wider pool of developers and improves much more quickly. It is easy to find examples of code which, after languishing for years out of the mainline, improved quickly after being merged. This is the reasoning behind the -staging tree and the general policy toward merging drivers sooner rather than later.

  • Some developers - sometimes, amusingly, the same developers - say, instead, that the best time to get fundamental problems fixed is before merging. This is undoubtedly true for user-space ABI issues; those often cannot be fixed at all after they have been shipped in a stable kernel. But holding code out of the mainline is also a powerful lever which subsystem maintainers can employ to motivate developers to fix problems. Once the code is merged, that particular tool is no longer available.

Both of these themes run through the Xen discussion. There is no doubt that the Xen Dom0 code would see more eyeballs - and patches - after being merged. So some developers think that the right thing to do is to merge this much-requested feature, then fix it up afterward. Chris Mason put it this way:

The idea that we should take code that is heavily used is important. The best place to fix xen is in the kernel. It always has been, and keeping it out is just making it harder on everyone involved.

But the stronger voice looks to be the one saying that the problems need to be fixed first. The deciding factors seem to be (1) the user-space ABI, and (2) the intrusion into the core x86 code; those issues make Xen different from yet another driver or filesystem. That, in turn, suggests that the Dom0 code is not destined for the mainline anytime soon. Instead, the Xen developers will be expected to go back and fix a list of problems - a lot of work with an uncertain result at the end.

Comments (53 posted)

Page sanitization, part 2

By Jake Edge
June 3, 2009

Last week's Security page looked at some recently proposed patches that would "sanitize" kernel memory by clearing it as it was freed. At that time, a second version of the patches which unconditionally cleared memory when freed—dependent on the sanitize_mem boot parameter—was generally well received. But, perhaps folks just had not yet had a chance to look. Over the last week, multiple objections have been raised, which were mostly met with belligerent responses from developer Larry Highsmith. In many ways, this is starting to look like yet another lesson in "how not to work with the kernel community".

The basic problem is that data can persist in memory long after that memory is freed. Sometimes that data contains passwords, cryptographic keys, confidential documents, etc., but it is impossible for the kernel to know, in the general case, which pages are sensitive. By clearing memory when it is deallocated, the lifetime of this potentially sensitive data can be reduced. A research paper describes some experiments that showed memory values persisting for days and even weeks on Linux systems. A bug in the kernel that leaked memory information could potentially leak these values to attackers.

So, Highsmith proposed adding a memory sanitization feature that has long been a part of the patches applied to the kernel by the PaX security project. There is clearly a performance impact to clearing memory as it is reclaimed, but, since memory is cleared as it is allocated (to avoid obvious information leaks), the impact may not be as large as it seems at first glance. As Arjan van de Ven points out:

.. and if we zero on free, we don't need to zero on allocate. While this is a little controversial, it does mean that at least part of the cost is just time-shifted, which means it'll not be TOO bad hopefully...

Peter Zijlstra is concerned about the cache effects: "zero on allocate has the advantage of cache hotness, we're going to use the memory, why else allocate it. [...] zero on free only causes extra cache evictions for no gain." But van de Ven describes how he sees the caches being affected, concluding: "Don't get me wrong, I'm not arguing that zero-on-free is better, I'm just trying to point out that the 'advantage' of zero-on-allocate isn't nearly as big as people sometimes think it is..."

But some, like Alan Cox, think the performance impact is immaterial: "If you need this kind of data wiping then the performance hit is basically irrelevant, the security comes first." Zijlstra and others are concerned about the price that is paid by all kernel users, even those who have not enabled sanitize_mem. He notes that the patches would add extra function calls and branches even when the feature is not enabled. Suggestions were made to benchmark the proposed code against the existing implementation, but that is where the conversation started to go off the rails.

Highsmith obviously gets frustrated with the direction of the discussion, but rather than stepping back, he lashes out. There is certainly some provocation in the thread, Zijlstra's "Really, get a life, go fix real bugs. Don't make our kernel slower for wanking rights." comment certainly didn't help. But Highsmith needs to recognize that he is the one trying to get something added to the kernel, so the burden of "proof" is on him. Instead, his condescending manner seems to indicate that he feels like he is presenting the kernel community with a gift—one they are too slow-witted to understand.

An important characteristic for kernel contributors is that they work well with the rest of the community: answer questions, respond to code review suggestions, etc. When that doesn't happen, patches tend to be ignored, regardless of their technical merit, and Highsmith seems headed down that path. When it was suggested that using kzfree() on specific kernel allocations for sensitive data—which would clear the memory, then free it—Highsmith responded:

That's hopeless, and kzfree is broken. Like I said in my earlier reply, please test that yourself to see the results. Whoever wrote that ignored how SLAB/SLUB work and if kzfree had been used somewhere in the kernel before, it should have been noticed [a] long time ago.

Since Highsmith was responding to SLAB maintainer Pekka Enberg's suggestion, that response—even if true—probably wasn't the right approach. Enberg and others asked specifically about the problems in kzfree(), but the response from Highsmith was a combination of condescension and vagueness. As soon as Enberg and Ingo Molnar tried to pin down where those problems are, Highsmith went off on a rant about the SLOB memory allocator.

In addition, Molnar has pointed out that some of the same sensitive values can have long lifetimes on the kernel stack:

Long-lived tasks that touched any crypto path (or other sensitive data in the kernel) and leaked it to the kernel stack can possibly keep sensitive information there indefinitely (especially if that information got there in an accidentally deep stack context) - up until the task exits. That information will outlive the freeing and sanitizing of the original sensitive data.

Rather than recognize this as an additional area that needs addressing, Highsmith just continues his tirade:

But you and the other cabal of vagueness have only sent mostly useless comments, outright uncivil responses, obvious misdirection attempts, unfounded critics, etc. I haven't seen more fallacies put together since the last time I read an unreleased film script by Jerry Lewis.

Overall, the idea of clearing memory as it is freed based on a boot time flag is reasonable. Several kernel hackers, including Cox and Rik van Riel, have expressed interest in seeing the feature added. With some effort, it would seem that the performance cost for the disabled case could be reduced to an acceptable level, but if the main proponent is spending his time fighting and flaming, it seems unlikely that it will ever get merged.

A newer set of patches, which just use kzfree() in specific sensitive places (tty buffer management, 802.11 key handling, and the crypto API) were also proposed by Highsmith, but Linus Torvalds was not particularly impressed. There was no need to use kzfree() there, a simple memset() was sufficient. Torvalds was not necessarily a believer in the need for the patches, nor for how Highsmith responded to review:

but quite frankly, I'm not convinced about these patches at all.

I'm also not in the least convinced about how you just dismiss everybodys concerns.

There were some additional technical complaints about the patches as well, particularly the use of kzfree() everywhere in the crypto API patch. Crypto API maintainer Herbert Xu noted: "The zeroing of metadata is gratuitous." Overall, they had the look of being created grudgingly—as if it were a favor to do so.

Where things go from here is unclear. Highsmith seemed to possibly be signing off in his reply to Torvalds: "The next time a kernel vulnerability appears that is remotely related to some of the venues of attack I've commented, it will be useful to be able to refer to these responses." There is some justification for Highsmith's frustration, but he needs to see that it isn't going to do him (or the kernel) any good.

Kernel contributors, especially new ones, need to recognize that the community has folks that are at least as smart as they are. In this case, some of those developers may not have the security focus that Highsmith does, but that doesn't reduce their understanding of the kernel, nor their interest in seeing it have patches applied for better security. It would be unfortunate to see this feature, which could be very useful in some environments, fall by the wayside.

Comments (11 posted)

Patches and updates

Kernel trees

Core kernel code

Development tools

Device drivers

Filesystems and block I/O

Memory management

Networking

Architecture-specific

Security-related

Virtualization and containers

Benchmarks and bugs

Miscellaneous

Page editor: Jonathan Corbet

Distributions

News and Editorials

An interview with openSUSE community manager Joe Brockmeier

By Rebecca Sobol
June 3, 2009

The openSUSE project held a Community Week, May 11 - May 17, 2009. Community Week provided a chance for people from around the world to get together and focus on specific topics, to transfer knowledge about openSUSE to users and contributors and to help build teams.

We talked with openSUSE community manager Joe "Zonker" Brockmeier about Community Week and the upcoming openSUSE Conference.

This was an IRC conference, with different sessions on different channels. Was it possible to attend all sessions? How many sessions were there?

That's correct. It probably wouldn't be possible to attend all sessions, since some were held simultaneously and they were also across all different time zones. Since we have to accommodate people from all time zones, it would have meant being up ridiculously early or late to be in all sessions. However, we repeated many of the sessions so that interested contributors didn't have get up at 4 a.m. or stay up to 11 p.m. to get the session they wanted to attend.

How many sessions did you attend?

I was in quite a few. I was actually logged into several channels at the same time, sort of watching one session while being more active in others.

I read somewhere that this was the first annual event. Are there any specific plans for next year?

I don't think we said "annual," just first. We are discussing doing this again, probably in a more limited scope, maybe one day a month and one session a week.

How much participation was there?

Quite a bit. Some of the IRC channels had about 50% more users/nicks than usual while sessions were going on, I'd guesstimate that we had several hundred people turn out that aren't usually in IRC for sessions.

Do you think it was a success? What was particularly successful about it?

I do think it was a success. It got people talking about how to contribute to the project and gave us a chance to focus on new contributors. What was really good in my opinion was that we had several community members step up and plug in sessions where they felt there was a need and take leadership to run their own sessions.

What didn't work as well?

The only real reservation I have looking back is that we probably should have only run one session at a time, and that we bit off quite a bit going a full week. The organization required to do it was fairly heavy, and it'd be better to have a more lightweight process and shorter schedule in the future -- but more often.

Was there a specific highlight or two of things that were interesting, useful, unexpected, etc?

Most of the sessions were useful, so I don't know if I'd call out any as being more useful than others. As I mentioned, I was very pleased to see some of the community just taking initiative and setting up sessions on their own. That's great to see and I'd love to see more of it.

For people who didn't participate, but are now interested in getting involved, where is the right place to go for info?

It's a bit outdated, but this is the best place to start: http://en.opensuse.org/How_to_Participate

The mailing lists are also a good place to start. It can be a bit intimidating, asking a first question on a project mailing list, but we're happy to help people get started. If you're not sure which list to start with, then an introductory mail on the openSUSE-Project mailing list would be a good way to get started -- just say where you'd like to be involved and we'll help you get started.

Tell us about the upcoming openSUSE Conference.

Sure. We're going to be running a four-day conference for openSUSE contributors in Nuremberg, Germany from September 17 through 20th. This is a free event, anyone can attend. openSUSE has contributors from around the world, and this is a chance to get a bunch of contributors together, meet face to face, and get some work done together.

Befitting that, the conference will be partially dedicated to presentations and talks, but also have a huge amount of "unconference" time where attendees can plan their own sessions or have hacking/working sessions rather than just attending presentations. The call for participation is still open, so anyone who'd like to lead a session or give a presentation should sign up: http://en.opensuse.org/OpenSUSE_Conf_2009/Call_for_Papers

It's open to anybody who is interested in contributing to openSUSE. We'll have sessions for newer contributors on packaging, etc. as well as a lot of hands-on activity.

We'll also have an "Open Day" Saturday for new Linux users with some content for people who are new to Linux and openSUSE.

Is there anything else you would like to add?

Sure - we just released openSUSE 11.2 Milestone 2 today [May 28]. This is leading up to the openSUSE 11.2 release scheduled for November. This is an ideal time for anybody who would like to start contributing to the project. The release announcement is here.

Thanks for taking the time to answer our questions.

Comments (none posted)

New Releases

openSUSE 11.2 Milestone 2 released

The second openSUSE 11.2 milestone release is available. "Help us make openSUSE 11.2 the best release yet! Please run the release through your usual routine, and let us know about any bugs or other issues that you find. Remember that this is a milestone release, and is not suitable for use on production systems." Lots has changed since the first milestone; it has a 2.6.30-rc kernel, ext4 as the default filesystem, and a fair amount of other leading-edge stuff.

Full Story (comments: none)

Celebrating the release of OpenSolaris 2009.06!

OpenSolaris 2009.06, the third release of the OpenSolaris Operating System has been announced. Click below for more information.

Full Story (comments: none)

Distribution News

Fedora

Fedora 11 slips again

A last-minute installer bug has caused the Fedora 11 release to be pushed back one more week. "The change is important but invasive enough to require re-validating our storage tests. We were already late in producing the Release Candidate and there is not enough time to produce another one and validate it in time for next Tuesday's release date. Therefor we have decided to enact another week long slip of the release." The schedule now calls for a June 9 release.

Full Story (comments: none)

Announcing Fedora Activity Day - Fedora Development Cycle 2009

A Fedora Activity day is coming up soon. "This activity day is for maintainers, QA, and release engineering folks to meet and discuss ongoing issues with the Fedora Development Cycle and to create a proposal on how to fix many of the issues. Note, this is not an event to decide on a solution, it is an event to decide on a proposal, which will then be shared with the whole community for more input and work."

Full Story (comments: none)

Gentoo Linux

Gentoo council summary for May 28

Click below for a summary of the Gentoo council meeting on May 28, 2009. Topics include Filling the empty council seat, EAPI 3 status report from Zac Medico, Removal of Old Eclasses, and Handling EAPI Versioning in a forwards-compatible way.

Full Story (comments: none)

SUSE Linux and openSUSE

Some openSUSE Factory changes

The openSUSE project has announced some upcoming changes to how its development distribution is managed in what appears to be an attempt to make it more flexible and open to outsiders. "Currently, we have some policies around the distribution that date back to the time when there was no openSUSE. Code contributions are only possible if you go through a Novell developer. The same thing is true if you want to make some technical decision." The plan calls for splitting Factory into a number of smaller units and allowing each one to make its own decisions on management and maintenance.

Full Story (comments: none)

Ubuntu family

Ubuntu hppa end-of-life

Ubuntu's hppa port will not be supported in the future. "This is to announce the end-of-life for ubuntu/hppa. The final release of ubuntu on hppa is jaunty. Builds will continue on a best-effort basis for dapper/hppa, hardy/hppa, intrepid/hppa, and jaunty/hppa until those releases go end-of-life."

Full Story (comments: none)

Linux New Media Launches Ubuntu User Magazine

Linux New Media USA, LLC, has announced the launch of a new print publication, Ubuntu User magazine. "Canonical's popular Ubuntu operating system continues to win followers around the world, and Ubuntu User is the first print magazine specifically for this rapidly growing audience."

Full Story (comments: none)

Other distributions

CentOS 2 i386 End Of Life

CentOS 2 has reached its end of life, updates for CentOS-2 ended on May 31, 2009. "It is recommended that any system still running CentOS 2 should be upgraded to a more recent version of CentOS to ensure continued security and bug fix support." Click below for more information.

Full Story (comments: none)

Distribution Newsletters

CentOS Pulse - The Bi-weekly CentOS Newsletter #0901

The first CentOS Pulse newsletter has been announced. "This first issue centers around improving communication within the CentOS community and how that relates to the CentOS Promo SIG. We also look at the recent announcements regarding the CentOS LiveCD and the CentOS Directory Server. And dive into interesting community threads and the latest CentOS security updates."

Comments (none posted)

Misc Debian developer news (#16)

This issue of miscellaneous news for Debian developers covers GCC 4.4 related build failures tracked in the BTS, Debian is switching to EGLIBC, Debian Common Language Infrastructure (CLI) mailing list, New upload queue for European Developers, and Updates of LXDE.

Full Story (comments: none)

DistroWatch Weekly, Issue 305

The DistroWatch Weekly for June 1, 2009 is out. "OpenSolaris 2009.06, the third official release of the increasingly influential UNIX alternative for the desktop, is here! With a large number of new features and updated applications, it is bound to excite everybody interested in free operating systems. But will it also entice the average desktop user? That remains to be seen. In other news, Fedora slips the release of version 11 "Leonidas" by another week, FreeBSD gets set to enter code freeze in preparation for version 8.0, NetBSD receives a new binary package manager to offer a more APT/YUM-like package management experience, Debian gets improved support for Eee PC netbooks, and the openSUSE community announces Goblin - a new Moblin and openSUSE-based distro for netbooks. Also in this issue, the feature article takes a look at a minimalist, yet highly usable and well-designed Debris Linux, while the tips and tricks section returns with an article on running "Factory", the openSUSE development branch. Finally, we are pleased to announce that the recipient of the May 2009 DistroWatch.com donations is SliTaz GNU/Linux. Happy reading!"

Comments (none posted)

Fedora Weekly News 178

The Fedora Weekly News for May 31, 2009 is out. "This week's issue starts off with some poetry on next week's expected Fedora 11 release, and much activity on upcoming Fedora activity days, dev cons, and events. In news from the Fedora Planet, we learn about SELinux sandbox, an overview on virtualization features in F11, several musings on aspects of open source projects/communities, and a feature interview with Fedora Project leader Paul W. Frields. The Quality Assurance beat details the QA weekly meeting leading up to F11 next week, F11 FAQ work, and release candidate testing detail. Development asks whether gNaughty is indeed a Hot Babe, detail on getting graphics support working for the Fedora Live USB with the Chrome9 Vx800 GPU, and suggestions on upgrading to F11 via yum. In Translation news, upcoming F11 website translation details and a new member of the Romanian translation team. This issue is rounded out with an overview of the security advisories for Fedora 9 and 10 this past week. Enjoy this issue and get ready for Fedora 11 a week from tomorrow!"

Full Story (comments: none)

The Mint Newsletter - issue 85

The Mint Newsletter for June 2, 2009 covers the release of Mint 7 Gloria and much more.

Comments (none posted)

OpenSUSE Weekly News/73

This issue of the OpenSUSE Weekly News covers Moblin v2.0 Beta on openSUSE, Andrew Wafaa: New openSUSE Netbook Images, Dominique Leuenberger : RPM packaging for beginners, Stephen Shaw: iFolder on openSUSE 11.1, eweekeurope: OpenOffice.org 3.1 - Better Performance, and more.

Comments (none posted)

OpenSUSE Weekly News/74

This issue of the OpenSUSE Weekly News covers the openSUSE Ambassadors Program, openSUSE Education, Gnome 2.26.2 for openSUSE 11.1, Ben Kevan : How to find out how long a process has been running, Duncan Mac-Vicar: Facebook on Kopete, take II, and more.

Comments (none posted)

PCLinuxOS Magazine, Special issue

A special issue of PCLinuxOS Magazine is available. Topics include PCLinuxOS is great, Impressive Quality, Testimonial, PCC, and more.

Comments (none posted)

Ubuntu Weekly News #144

The Ubuntu Weekly News for May 30, 2009 is out. "In this issue we cover Ubunutu Forums Tutorial of the Week, New Ubuntu One sub-forum, In The Press, In The Blogosphere, the latest Ubuntu-UK Podcast, Meeting Summaries, Lo``Co Teams, Upcoming Events, and much, much more!!"

Full Story (comments: none)

Interviews

Fedora 11: Raise thy Mighty... Finger? (MadRhetoric)

Jack Aboutboul has interviewed Bastien Nocera. "Authentication is an aspect of computing which many take for granted. What's all the fuss? you think. Username, password and that's that. In the following Q&A session with Bastien Nocera, long time Fedora Contributor and Desktop Renaissance Man, we discover that when it comes to authentication, there is more than meets the finger!"

Comments (3 posted)

Page editor: Rebecca Sobol

Development

Jetpack: Firefox extensions as they should be

June 3, 2009

This article was contributed by Koen Vervloesem

One of the great strengths of Firefox is its extensions ecosystem. Over 12,000 enhancements for the browser are available, varying from additions of simple features to complete applications such as IRC or FTP clients. Many users just keep Firefox as their default browser because they can't live without specific extensions that don't exist in other browsers. This hackable nature of Firefox is something that Mark Surman of the Mozilla Foundation has emphasized countless times, for example in his keynote at FOSDEM 2009 a few months ago: only the ability to extend the web makes it truly the user's web.

Unfortunately, developing a Mozilla Firefox extension is far from easy. It requires a fair bit of knowledge of a strange mix of technologies: RDF (Resource Description Framework), XUL (XML User Interface Language), XPI (Cross-Platform Installer), XPConnect, XPCOM (Cross-Platform Component Object Model), DOM (Document Object Model), JavaScript and CSS (Cascading Style Sheets). Hence, the user willing to enhance his browser has to become well-versed in a long list of arcane languages.

To address this, the Mozilla Add-ons blog posed the question "How can we make the development of extensions easier?" and published an Extension Developer Survey. The top 5 requests were more concerned about the review queue, documentation, tutorials and writing and debugging tools, but several responses suggested some improvements to the add-on platform itself:

  1. not requiring browser restart for installation
  2. better debugging tools
  3. better packaging
  4. easier way to write extensions
  5. code generation/IDE

The Mozilla developers have clearly listened to these suggestions, as last week Mozilla Labs announced Jetpack, a new experimental extensions architecture which abstracts away much of the complexity of the current extensions system. The Jetpack API addresses the five issues mentioned above and at the same time lowers the bar for users by requiring only knowledge of HTML, CSS and JavaScript. This means that everyone with basic web development skills is able to extend their web browser using the same web technologies they already know. The choice for these web standards is also clever because it means that extension developers can re-use existing web development and debugging tools. For example, a Jetpack extension writer is able to use the Firebug extension (a popular extension for debugging, editing and monitoring CSS, HTML, DOM, and JavaScript) to develop his add-on.

Writing a Jetpack extension

To get started, users have to install the Jetpack Extension and restart Firefox. The browser then shows the about:jetpack page, which contains some Jetpacks (extensions created with the Jetpack API). Jetpack community lead Nick Nguyen writes on his blog how easy it was for him to develop a new Jetpack:

I was able to put together a Delicious Notifier Jetpack Feature in less than an hour using simple JQuery, CSS, and html. All I did was install the GMail Notifier widget and pasted it into Bespin, read the 20 lines of code that made it work, and started hacking away to get the information i wanted. Since I didn’t have to restart and could inspect and debug via Firebug, development was painless.

There are some demos one can use for inspiration, as Nguyen showed in his blog. The Jetpack Tutorial is also very helpful to start. Developing a Jetpack extension turns out to be surprisingly simple. It's an iterative process where the developer writes some code right in his browser, refreshes a web page to see the effect of his changes in the Jetpack extension code, then continues rewriting his code, and so on. One especially interesting feature is that Jetpack has automatically included jQuery by default. This popular JavaScript library exposes a lot of functionality, like DOM traversal and modification, events, CSS manipulation and Ajax. The tutorial shows how to write a script of only ten lines that removes embed elements from a page on-demand and at the end of the tutorial, the user learns how to write his own GMail notifier. Jetpack also has a Twitter library and will see more common web APIs in the future, including the ability to import external libraries.

At the moment, the API reference is woefully incomplete, but this should change as people start to experiment with Jetpack. Most of the interesting objects reside in the jetpack namespace. For example, the jetpack.notifications object can be used to display a notification message, and by using jetpack.tabs properties, the developer is able to manipulate the browser's tabs.

Even distributing a Jetpack extension is simple: just drop the code into a JavaScript file. Add a link element to a page:

    <link rel="jetpack" href="js-file">

Subsequently, a visitor to the page will see a notification bar with the option to install the Jetpack. It's also nice to see the developers have thought about security: the user sees the whole Jetpack extension source code before he installs it. In the future, the Jetpack system will work with a "social trust network" to help people make informed decisions about whether to install a Jetpack extension or not.

When using Firefox 3.0 or earlier, any logging messages or errors produced by Jetpacks reference the wrong line numbers, which makes debugging Jetpacks difficult. So anyone planning to experiment with Jetpack should consider using Firefox 3.5 Beta. Moreover, if the user doesn't have the latest version of Firebug installed, all logging messages appear in the JavaScript Error Console. For serious debugging, the Jetpack developers strongly suggest using Firebug 1.4 Alpha.

Conclusion

At the moment Jetpack is still an early prototype (that's why it's in Mozilla Labs), and it is not meant to replace the existing extension system. It is however well-suited for simple addititions to Firefox, analogous to the changes users can make to web pages with Greasemonkey. For this purpose, Jetpack clearly looks like the right choice: it not only makes developing extensions much simpler, but it creates new possibilities, such as installing an extension without the need to restart the browser.

Comments (7 posted)

System Applications

Database Software

cryha 1.0 announced

Version 1.0 of cryha has been announced. "Cryha is a Python toolkit for securing information into a data base; it lets hash passwords, and encrypt/decrypt personal information. It is ready for input of Unicode characters, and the schema is returned as Unicode."

Full Story (comments: none)

MySQL Community Server 5.0.82 released

Version 5.0.82 of MySQL Community Server has been announced. "MySQL Community Server 5.0.82, a new version of the popular Open Source Database Management System, has been released. This and future releases in the MySQL Community Server 5.0 series share version numbers with their MySQL Enterprise Server counterparts."

Full Story (comments: none)

PostgreSQL Weekly News

The May 31, 2009 edition of the PostgreSQL Weekly News is online with the latest PostgreSQL DBMS articles and resources.

Full Story (comments: none)

PowerConsole 0.7 released

Version 0.7 of PowerConsole has been announced. "PowerConsole is an enhanced Python interpreter that can host user defined commands. It uses pyparsing-based grammars for user commands to translate them into python calls, so it has limited support for mixing them with Python code. A basic, ready to use CLI interpreter is included."

Comments (none posted)

Embedded Systems

BusyBox 1.14.1 released

Stable version 1.14.1 of BusyBox, a collection of command line utilities for embedded systems, has been announced. "Bug fix release. Contains fixes in acpid, awk, depmod, dhcp, gzip, mdev, modprobe, sysctl; libbb fixes. hush is significantly updated."

Comments (none posted)

Interoperability

Samba 3.4.0pre2 is available

Version 3.4.0pre2 of Samba has been announced. "This is a preview of the next upgrade production release version of Samba. It is intended for testing purposes only. Please test and report any bugs that you find. The final 3.4.0 release is planned for July 1, 2009."

Comments (none posted)

Web Site Development

TurboGears 2.0 final released

Version 2.0 final of the TurboGears web development framework has been announced. "This release is the product of a lot of work by the whole TurboGears team, and we're very happy to have a final stable release. TurboGears 2.0 final includes all kinds of goodies for those making web applications, from one of the most powerful and flexible Object Relational Mappers available in any language, to a powerful and flexible template system. But just as important as the quality of the parts, is the out-of-the-box integration to help get you started quickly".

Full Story (comments: none)

Desktop Applications

Data Visualization

SUMMON 1.8.7 released

Version 1.8.7 of SUMMON has been announced. "SUMMON is a python extension module that provides rapid prototyping of 2D visualizations. By heavily relying on the python scripting language, SUMMON allows the user to rapidly prototype a custom visualization for their data, without the overhead of a designing a graphical user interface or recompiling native code. By simplifying the task of designing a visualization, users can spend more time on understanding their data."

Full Story (comments: none)

Desktop Environments

GNOME 2.27.2 released

Version 2.27.2 of GNOME has been announced. "This is the second development release towards the wonderful 2.28 release! Various bug fixes and nice improvements in several modules. Fun, fun, fun!"

Full Story (comments: none)

GNOME Software Announcements

The following new GNOME software has been announced this week: You can find more new GNOME software releases at gnomefiles.org.

Comments (none posted)

KDE 4.2.4 released

Version 4.2.4 of KDE has been announced. "KDE Community Ships Fourth Translation and Service Release of the 4.2 Free Desktop, Containing Numerous Bugfixes, Performance Improvements and Translation Updates".

Full Story (comments: none)

KDE Software Announcements

The following new KDE software has been announced this week: You can find more new KDE software releases at kde-apps.org.

Comments (none posted)

Xorg Software Announcements

The following new Xorg software has been announced this week: More information can be found on the X.Org Foundation wiki.

Comments (none posted)

Electronics

Butterfly Platform FPGA Design 1.0 (OpenCollector)

OpenCollector.org has announced version 1.0 of the Butterfly Platform. "The Butterfly Platform is a modular FPGA development platform. All schematics, board files, and utilities are released under a Creative Commons Attribution license. The schematic and board files are available in the popular Eagle PCB design format. The Butterfly Platform is incredibly flexible and can be programmed to be a logic analyzer one minute and then a flash programmer the next. Some possible applications are: -Logic Analyzer -Flash Programmer -Frequency Generator -Frequency Counter -PWM controller (20+ Channels are possible) -8 Bit Microcontroller -32 Bit Microcontroller -Future versions will be able to run ucLinux".

Comments (none posted)

Music Applications

Virtual MIDI Piano Keyboard 0.2.5 released

Version 0.2.5 of Virtual MIDI Piano Keyboard has been announced. "Virtual MIDI Piano Keyboard is a MIDI events generator and receiver. It doesn't produce any sound by itself, but can be used to drive a MIDI synthesizer (either hardware or software, internal or external). You can use the computer's keyboard to play MIDI notes, and also the mouse. You can use the Virtual MIDI Piano Keyboard to display the played MIDI notes from another instrument or MIDI file player."

Full Story (comments: none)

Office Applications

HylaFAX 6.0.2 released

Version 6.0.2 of HylaFAX, a fax modem interface program, has been announced. "This release is a maintenance release, and does not contain any new features or functionality, but only bugfixes".

Comments (none posted)

Office Suites

KOffice 2.0.0 released

The KOffice 2.0.0 release is out. "KOffice 2 is a much more flexible application suite than KOffice 1 ever was. The integration between the components is much stronger, with the revolutionary Flake Shapes as the central concept. A Flake Shape can be as simple as a square or a circle or as complex as a chart or a music score. With Flake, any KOffice application can handle any shape. For instance, KWord can embed bitmap graphics, Krita can embed vector graphics and Karbon can embed charts. This flexibility does not only give KOffice unprecedented integration, but also allows new applications to be created very easily. Such applications can e.g. target special user groups like kids or certain professions." The announcement also compares this release to KDE 4.0, in that not all features are there yet.

Comments (7 posted)

Languages and Tools

Caml

Caml Weekly News

The June 2, 2009 edition of the Caml Weekly News is out with new articles about the Caml language.

Full Story (comments: none)

Java

IcedTea 1.10 released

Version 1.10 of IcedTea, a harness for building source code from OpenJDK, has been announced. A number of new capabilities and bug fixes have been added.

Full Story (comments: none)

IcedTea6 1.5 released

Version 1.5 of IcedTea6, a harness for building source code from OpenJDK6, has been announced. A number of new capabilities and bug fixes have been added.

Full Story (comments: none)

Perl

Rakudo Perl 6 development release #17 (use Perl)

use Perl has announced development release #17 of Rakudo Perl 6, an implementation of Perl 6 on the Parrot Virtual Machine. Changes include: "* Rakudo is now passing 11,342 spectests, an increase of 875 passing tests since the April 2009 release. With this release Rakudo is now passing 68% of the available spectest suite. * We now have an updated docs/ROADMAP . * Errors and stack traces now report the file name and line number in the original source code. * Some custom operators can be defined, and it's possible to refer to operators using &infix:<op> syntax. * We can start to load libraries written in other Parrot languages. * Regexes now produce a Regex sub. * More builtin functions and methods have been rewritten in Perl 6 and placed as part of the setting. * There are many additional improvements and features in this release, see docs/ChangeLog for a more complete list."

Comments (none posted)

Python

Python 3.1 release candidate 1 released

release candidate 1 of Python 3.1 is available. "On behalf of the Python development team, I'm happy to announce the first release candidate of Python 3.1. Python 3.1 focuses on the stabilization and optimization of the features and changes that Python 3.0 introduced. For example, the new I/O system has been rewritten in C for speed. File system APIs that use unicode strings now handle paths with undecodable bytes in them. Other features include an ordered dictionary implementation, a condensed syntax for nested with statements, and support for ttk Tile in Tkinter."

Full Story (comments: none)

itools 0.60.2 released

Version 0.60.2 of itools has been announced, it includes several bug fixes. "itools is a Python library, it groups a number of packages into a single meta-package for easier development and deployment".

Full Story (comments: none)

Numexpr 1.3 released

Version 1.3 of Numexpr has been announced. "Numexpr is a fast numerical expression evaluator for NumPy. With it, expressions that operate on arrays (like "3*a+4*b") are accelerated and use less memory than doing the same calculation in Python. On this release, and due to popular demand, support for single precision floating point types has been added."

Full Story (comments: none)

Python-URL! - weekly Python news and links

The May 29, 2009 edition of the Python-URL! is online with a new collection of Python article links.

Full Story (comments: none)

Tcl/Tk

Tcl-URL! - weekly Tcl news and links

The May 28, 2009 edition of the Tcl-URL! is online with new Tcl/Tk articles and resources.

Full Story (comments: none)

Libraries

SLV2 0.6.6 is available

Version 0.6.6 of SLV2 has been announced. "SLV2 is a library to make the use of LV2 plugins as simple as possible for applications. Changes this release: * Add manual pages for utilities * Reduce plugin load overhead (on-demand querying with finer granularity) * Fix compilation on Mac OS X"

Full Story (comments: none)

Page editor: Forrest Cook

Linux in the news

Recommended Reading

Born free (Economist)

The Economist looks at the growth of free software during the recession. "For years, this software commons was no more than an obscure sideshow. But then the internet provided volunteer programmers with a way to co-operate cheaply. IBM and Oracle, two industry giants, threw their weight behind the Linux operating system, in part to weaken their rival Microsoft. After the dotcom bubble burst in 2001, many firms turned to Linux and other open-source software to save money."

Comments (10 posted)

Companies

IBM Entices Sun, HP Customers onto Linux Mainframes (eWeek)

eWeek looks at IBM's efforts to move customers to Linux mainframes. "With enterprises looking to consolidate their data center infrastructures, some are turning to the mainframe platform, particularly in combination with Linux, he said. According to IBM, almost 2,800 of the 5,000 unique applications available for the System z platform are Linux-based, and Linux accounted for about half of the 1,000 or so new and updated applications created for the IBM mainframe in 2008. In addition, more than 40 percent of new System z customers in 2008 installed Linux."

Comments (4 posted)

Microsoft installs Firefox extension without asking (The H)

The H has a report about a Firefox extension that was installed as part of a Windows Update without user approval. It is interesting that Microsoft is now writing Firefox extensions, but they may want to look at their policy of automatic installation without any (easy) way to uninstall it. "The 'Microsoft .NET Framework Assistant' add-on uses ClickOnce technology to allow users to install Windows applications by clicking a link in a web page. A number of people have raised concerns over the security of the technology, objected to the fact that the Service Pack installs the extension without asking and complained that once installed, the Uninstall button in the Firefox Add-on panel is greyed-out and the extension cannot easily be uninstalled (although it can be disabled)."

Comments (17 posted)

Novell Linux revenue soars as global server revenue plummets (CNet)

CNet takes a look at Novell's second quarter results. "Novell reported $37 million in Linux Platform Products revenue, up 25 percent compared to the same period last year. While not on par with Red Hat's continued growth -- 18 percent last quarter on a higher revenue base, -- Novell's execution on its Linux Platform business, in particular, is impressive."

Comments (8 posted)

Linux Adoption

UN buys into Ncomputing's Linux thin-client PCs (The Inquirer)

The Inquirer reports on a United Nations project to get 1000 Linux-based thin clients into schools in developing countries. "Ncomputing will not only provide its One-Watt thin-client devices but will also provide logistical and operational support for deployment in primary and secondary schools through 2012. A pilot project has already been completed in Burkina Faso, with more projects scheduled for Rwanda, Senegal and Tanzania in 2009."

Comments (2 posted)

Resources

Introducing Three Python Web Frameworks (Linux Journal)

Paul Barry introduces Django, Pylons and TurboGears in a Linux Journal article. "What with all the hoopla surrounding Ruby on Rails, aspiring Web application programmers should be forgiven for assuming that Rails is the only way to go when building their next great Web app. But, Rails is not the only game in town, and Ruby is not the only language worth considering in this very active area. Perl has a large and growing collection of Web frameworks, including Maypole, Catalyst, Jifty and Gantry (to name a few). Even in the Ruby space, the list of technologies is growing to include Merb, Camping, Nitro/Og and Ramaze. And, let's not forget some of the projects from the world's favorite Web templating language, PHP: Zoop, Jelix, Cake and Biscuit."

Comments (27 posted)

Xorg's X Window innovation - it's not ALL about the graphics (FSM)

Free Software Magazine has a wide-ranging look at what's going on around graphics programming. "Right now, LLVM is being developed, and a front-end made, to become a hardware-agnostic shaders compiler that will be part of Gallium. Currently, it works as an advanced prototype, and experiments are being made to support fully programmable shaders on cards that only support fixed function shaders without resorting to ‘pure’ software emulation: LLVM compiles shader fragments down to instructions that fixed function cards can render in an accelerated manner (it’s VERY experimental for now: it may be a dead end, so don’t bet on your Geforce3 card rendering current games in any usable way tomorrow!)."

Comments (3 posted)

Reviews

Hands on: Google Chromium browser alpha for Linux (ars technica)

ars technica reviews an alpha release of the Google Chromium browser. "We took a look at the Mac OS X port of Chromium a few months ago, but the Linux port was still barely functional at the time. A lot of progress has been made since then and the Linux version is now in the alpha stage. We tested it on Ubuntu 9.04 to see how it compares with the latest release of Chrome for Windows. There are still missing features and lots of rendering bugs, but it is clearly moving in the right direction."

Comments (none posted)

Linux-ready networking SoCs scale to 40 cores (LinuxDevices)

LinuxDevices takes a look at the latest System on a Chip processors from Netronome. "Netronome announced new multi-core "network flow processors" that are backward-compatible with Intel's IXP28xx, but claimed to offer over twice the MIPS. The Linux-compatible NFP-32xx system-on-chips scale from 16 to 40 cores, offer 20Gbps throughput, and provide a programmable dataplane, virtualization, and security processing, says the company."

Comments (1 posted)

NILFS: A File System to Make SSDs Scream (Linux Mag)

Linux Magazine has a look at the Nilfs2 filesystem which is part of 2.6.30. "One of the most noticeable features of NILFS is that it can 'continuously and automatically save instantaneous states of the file system without interrupting service'. NILFS refers to these as checkpoints. In contrast, other file systems such as ZFS, can provide snapshots but they have to suspend operation to perform the snapshot operation. NILFS doesn’t have to do this. The snapshots (checkpoints) are part of the file system design itself."

Comments (10 posted)

Page editor: Forrest Cook

Announcements

Non-Commercial announcements

FSF welcomes AdBard network for free software advertising

The Free Software Foundation (FSF) has welcomed the launch of AdBard, a new advertising network for technology based websites based upon the promotion of Free, Libre and Open Source Software (FLOSS) friendly products and services. "The AdBard Network has been created by Tag1 Consulting to serve websites dedicated to free software ideals, helping them connect with companies selling products and services targeting a FLOSS audience. AdBard solves the problem that more generic advertising has led to the display of proprietary software products on sites that otherwise promote computer user freedom."

Full Story (comments: 8)

More changes at Openmoko

Sean Moss-Pultz has sent out an announcement on the future of Openmoko and the Freerunner phone. It seems that Openmoko has laid off much of its remaining staff and is getting out of the phone business. As part of that transition, it will be handing over as much information to the community as possible. "I am extremely excited about the idea of an entirely community-built open phone. Especially since, when the next design is complete, it will have the benefits of everything uncovered since the Freerunner shipped last July. It will be buzz free, glamo free, and free of the recamping bug (#1024) - which I am happy to announce has been solved this past week. We promise to support these efforts with additional resources such as components to build prototypes of the new design. We will help to empower you to build the open phone of our future." Meanwhile, Openmoko is headed off to work on "an altogether different type of device." (Thanks to Timo Jyrinki).

Full Story (comments: 12)

Happy ten thousandth anniversary to PLplot

The PLplot project has announced a new milestone: "PLplot is a cross-platform software package for creating scientific plots that has been in continuous development since its inception 17 years ago. On May 23, 2009 the PLplot developers quietly celebrated our ten thousandth commit since our initial software repository was populated back in May 1992."

Full Story (comments: none)

Commercial announcements

Universal software radio peripheral 2 available

Version 2 of the Universal Software Radio Peripheral (USRP) is now available for purchase. The USRP, in combination with GNU Radio, can be used to create a wide variety of software-driven radio devices. See the brochure [PDF] for more information on this device.

Full Story (comments: 14)

New Books

The Art of Concurrency - New from O'Reilly

O'Reilly has published the book The Art of Concurrency by Clay Bresheaers.

Full Story (comments: none)

Regular Expressions Cookbook--New from O'Reilly

O'Reilly has published the book Regular Expressions Cookbook by Jan Goyvaerts and Steven Levithan.

Full Story (comments: none)

Web 2.0 Architectures - New from O'Reilly

O'Reilly has published the book Web 2.0 Architectures by James Governor, Dion Hinchcliffe and Duane Nickull.

Full Story (comments: none)

Calls for Presentations

CFP 26C3 / 26th Chaos Communication Congress

A call for papers has gone out for the 26th Chaos Communication Congress. "[26C3] is the annual four-day conference organized by the Chaos Computer Club (CCC) in Berlin, Germany. First held in 1984, it since has established itself as "the European Hacker Conference" attracting a diverse audience of thousands of hackers, scientists, artists, and utopists from all around the world." The event takes place on December 27-30, submissions are due by October 9.

Full Story (comments: none)

ACSAC 2009 submissions deadline extended

The ACSAC 2009 submissions deadline has been extended to June 8 and June 10, the event takes place in Honolulu, HI on December 7-11, 2009. "ACSAC is an internationally recognized forum where practitioners, researchers, and developers in information system security meet to learn and to exchange practical ideas and experiences. If you are developing practical solutions to problems relating to network, system and information security, the[n] you should consider submitting your work to ACSAC and attending in December."

Full Story (comments: none)

FRHACK 2009 final call for papers extended

The final call for papers FRHACK 2009 has been extended to June 30. The event takes place in Besançon, France on September 7-11, 2009.

Full Story (comments: none)

2009 SELinux Developer Summit Call for Participation

A call for participation has gone out for the 2009 SELinux Developer Summit. "The summit will be held Sunday September 20th in Portland as part of LinuxCon. Note that all attendees must be registered as attendees of LinuxCon. Primary topics for this year's summit will be extensibility and usability, with a flexible format to include interactive talks and development sessions." Submissions are due by July 1.

Full Story (comments: none)

Upcoming Events

DebConf11 in your city

A call for location has gone out for DebConf11. "Every year, the location for DebConf, the annual international Debian conference, is selected via a competitive bid process. Although we haven't got to DebConf9 yet, organising a conference isn't quick, so it's already time to start thinking about a location for DebConf11. We encourage everyone to think about whether their city would make a good DebConf location, and, if it would, to start working on a proposal."

Full Story (comments: none)

EuroSciPy 2009 - presentation schedule published

The presentation schedule for EuroSciPy 2009 has been published. "We have 16 talks from a variety of scientific fields. All about using Python for scientific work. We're pleased to announce the EuroSciPy 2009 Conference to be held in Leipzig, Germany on July 25-26, 2009."

Full Story (comments: none)

LPI's 10th anniversary at LinuxTag Berlin

LPI will celebrate its 10th anniversary at LinuxTag Berlin on June 24-27, 2009. "The Linux Professional Institute, the world's premier Linux certification organization, announced a program of events and activities at LinuxTag, Berlin, Germany in celebration of the organization's 10th anniversary. Events during the conference have been organized by LPI affiliate, LPI-Central Europe and feature an information booth, seminars, forums, training partner and affiliate meetings, the ever popular and traditional exam labs, and finally social events."

Full Story (comments: none)

Announcing the PyPy Europython Sprints

The PyPy Europython Sprints have been announced. "The PyPy team is sprinting at EuroPython again. This year there are `sprint days`_ before (28-29 June) and after (3-4 July) the conference. Some PyPy core people should be present during both periods."

Full Story (comments: none)

Events: June 11, 2009 to August 10, 2009

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

Date(s)EventLocation
June 8
June 12
Ruby on Rails Bootcamp with Charles B. Quinn Atlanta, GA, USA
June 10
June 11
FreedomHEC Taipei Taipei, Taiwan
June 11
June 12
ShakaCon Security Conference Honolulu, HI, USA
June 12
June 13
III Conferenza Italiana sul Software Libero Bologna, Italy
June 12
June 14
Writing Open Source: The Conference Owen Sound, Canada
June 13 SouthEast LinuxFest Clemson, SC, USA
June 14
June 19
2009 USENIX Annual Technical Conference San Diego, USA
June 17
June 19
Open Source Bridge Portland, OR, USA
June 17
June 19
Conference on Cyber Warfare Tallinn, Estonia
June 20
June 26
Beginning iPhone for Commuters New York, USA
June 22
June 24
Velocity 2009 San Jose, CA, USA
June 22
June 24
YAPC|10 Pittsburgh, PA, USA
June 24
June 27
LinuxTag 2009 Berlin, Germany
June 24
June 27
10th International Free Software Forum Porto Alegre, Brazil
June 26
June 28
Fedora Users and Developers Conference - Berlin Berlin, Germany
June 26
June 30
Hacker Space Festival 2009 Seine, France
June 28
July 4
EuroPython 2009 Birmingham, UK
June 29
June 30
Open Source China World 2009 Beijing, China
July 1
July 3
OSPERT 2009 Dublin, Ireland
July 1
July 3
ICOODB 2009 Zurich, Switzerland
July 2
July 5
ToorCamp 2009 Moses Lake, WA, USA
July 3 PHP'n Rio 09 Rio de Janeiro, Brazil
July 3
July 11
Gran Canaria Desktop Summit (GUADEC/Akademy) Gran Canaria, Spain
July 4 Open Tech 2009 London, UK
July 6
July 10
Python African Tour : Sénégal Dakar, Sénégal
July 7
July 11
Libre Software Meeting Nantes, France
July 13
July 17
(Montreal) Linux Symposium Montreal, Canada
July 15
July 16
NIT Agartala FOSS and GNU/Linux fest Agartala, India
July 15
July 17
Kernel Conference Australia 2009 Brisbane, Queensland, Australia
July 18
July 19
Community Leadership Summit San Jose, CA, USA
July 19 pgDay San Jose San Jose, CA, USA
July 19
July 20
Open Video Conference New York City, USA
July 20
July 24
2009 O'Reilly Open Source Convention San Jose, CA, USA
July 24
July 30
DebConf 2009 Cáceres, Extremadura, Spain
July 25
July 26
EuroSciPy 2009 Leipzig, Germany
July 25
July 26
PyOhio 2009 Columbus, OH, USA
July 25
July 30
Black Hat Briefings and Training Las Vegas, NV, USA
July 26
July 27
InsideMobile San Jose, CA, USA
July 31
August 2
FOSS in Healthcare unconference Houston, TX, USA
August 3
August 5
YAPC::EU::2009 Lisbon, Portugal
August 7 August Penguin 2009 Weizmann Institute, Israel
August 7
August 9
UKUUG Summer 2009 Conference Birmingham, UK

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

Web sites

savannah.gnu.org status

The server that hosts GNU and other projects, savannah.gnu.org had a catastrophic failure over the weekend. A message in the savannah-users mailing list describes the problems with a RAID array which eventually led to filesystem corruption. This took out the source code repositories for the projects hosted there. "The last backup was performed while RAID was buggy, and lots of files were reported missing, in particular for CVS/SVN/Git/Hg. Hence the last backup is incomplete. [...] And, our last full backup from tape is from end of April. Normally tape backups are more recent, but there were independent backup issues. We've not discussed since in detail as we're focusing on recovering the data asap. " Status updates are available via fsfstatus on identi.ca. (thanks to David P. Reed).

Comments (40 posted)

Miscellaneous

Bilski case going to the U.S. Supreme Court

Scotusblog reports that the Bilski case will be reviewed by the US Supreme Court. "Not since 1981 has the Supreme Court undertaken to spell out the kinds of inventions that are eligible for patent rights — that is, the right to produce or use an invented device or process, or to license it to others for royalties. Much has changed since the Court’s decision in Diamond v. Diehr in 1981, not least the digital revolution."

Comments (9 posted)

Page editor: Forrest Cook

Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds