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.
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)
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)
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
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: |
|
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: |
|
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: |
|
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: |
|
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: |
|
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: |
|
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: |
|
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: |
|
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: |
|
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: |
|
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: |
|
Comments (none posted)
Page editor: Jake Edge
Kernel development
Brief items
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
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)
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)
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:
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:
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)
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)
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
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
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)
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
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)
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
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
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'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 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 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
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)
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)
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)
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 for
June 2, 2009 covers the release of Mint 7 Gloria and much more.
Comments (none posted)
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)
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)
A
special
issue of PCLinuxOS Magazine is available. Topics include PCLinuxOS is
great, Impressive Quality, Testimonial, PCC, and more.
Comments (none posted)
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
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
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:
- not requiring browser restart for installation
- better debugging tools
- better packaging
- easier way to write extensions
- 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 didnt 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
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)
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)
The May 31, 2009 edition of the PostgreSQL Weekly News
is online with the latest PostgreSQL DBMS articles and resources.
Full Story (comments: none)
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
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
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
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
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
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)
The following new GNOME software has been announced this week:
You can find more new GNOME software releases at
gnomefiles.org.
Comments (none posted)
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)
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)
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
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
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
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
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
The June 2, 2009 edition of the Caml Weekly News
is out with new articles about the Caml language.
Full Story (comments: none)
Java
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)
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
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
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)
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)
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)
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
The May 28, 2009 edition of the Tcl-URL! is online with new
Tcl/Tk articles and resources.
Full Story (comments: none)
Libraries
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
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
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)
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)
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
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
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)
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 (its VERY experimental for now: it may be a dead end, so dont bet on your Geforce3 card rendering current games in any usable way tomorrow!)."
Comments (3 posted)
Reviews
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)
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)
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 doesnt 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
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)
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)
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
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
O'Reilly has published the book
The Art of Concurrency
by Clay Bresheaers.
Full Story (comments: none)
O'Reilly has published the book
Regular Expressions Cookbook
by Jan Goyvaerts and Steven Levithan.
Full Story (comments: none)
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
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)
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)
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)
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
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)
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 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)
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) | Event | Location |
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
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
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 Courts decision in Diamond v. Diehr in 1981, not least the digital revolution."
Comments (9 posted)
Page editor: Forrest Cook