LWN.net Logo

LWN.net Weekly Edition for May 22, 2008

Blame Fedora. Again.

By Jonathan Corbet
May 21, 2008
As your editor writes, the Fedora development list is the scene of an extended, heated discussion about Fedora 9. One might think that some users would be unhappy about the inclusion of KDE 4, say, or maybe it's an issue with Firefox 3, with its refusal to run older extensions and persistent fsync() bug. It would not be hard to imagine users being upset by the continued presence of Codeina. In fact, nobody seems to have much to say about those issues. Instead, a small group of very vocal users is complaining about the X Window System.

That, too, might not be completely beyond imagination. Your editor can certainly attest that Rawhide users had more than their share of X-related fun over the course of the Fedora 9 development cycle. The interesting thing, though, is that just about all of the problems reported by Rawhide users got fixed before the final release. So, while Fedora 9 has a lot of very new X infrastructure, it seems to be fairly solid infrastructure.

The problem, instead, is that NVIDIA has not shipped a version of its binary-only graphics driver which works on Fedora 9. These vocal users feel that the Fedora Project has done them a major disservice by shipping a release without an NVIDIA-compatible X server. Instead, they say, Fedora should either have declined to ship a "pre-release" server, or it should provide a separate set of packages with an older server for NVIDIA users. NVIDIA seems to agree:

Fedora 9 is shipping a pre-release X server. If you can't wait for an updated NVIDIA graphics driver and the limited support provided in 173.08 graphics driver release is insufficient for your purposes, please use the X.Org nv driver or fall back to a supported distribution.

There are a few responses to be made to this set of claims, starting with the "pre-release" bit. The server is only "pre-release" by a relatively short period of time, and, more importantly, the ABI for this server release has been frozen for a few months now. The X developers have made it clear that the ABI will not change before the 1.5 release ships. So there's no real reason why NVIDIA could not release a driver if it chose to do so.

But NVIDIA has not so chosen. More to the point, NVIDIA has implemented a clear policy of not releasing drivers for a given X version until that version appears in a stable release by a major distribution. This is a policy which forces some distributor to ship a version of X which is not supported by NVIDIA. Criticizing a distribution like Fedora for being the first one out with a new X version seems misplaced; if one is averse to the use of new software, there are probably better distributions to be running.

But what about the compatibility packages request? Beyond the inconvenient fact that putting resources into supporting proprietary software is contrary to Fedora's policies, that sort of support is expensive to provide. See Adam Jackson's response for a blunt summary of just how expensive. If Fedora developers start putting their time into that sort of project, they will be putting less time into making Fedora itself better. This does not seem like a good tradeoff for Fedora users who, after all, have chosen a distribution with a "100% free software" policy.

And, certainly, some Fedora users appreciate the priorities that the developers have taken:

Well I'm an Intel & Radeon user and Xorg in F9 is dramatically better better for all my machines. So, yes, if new code improves life for the open source drivers, lets do this again & again in future releases. I don't want my desktop experience held hostage by one company with binary drivers.

In fact, X has gotten significantly better, and it has gotten better more quickly as a result of Fedora's decision to go with the upcoming release. Any attempt to maintain compatibility with proprietary drivers would, at best, slow that progress down significantly.

Users unquestionably have the right to hook binary-only drivers into their systems. But ensuring that those drivers work with current free software is their problem - not the free software developers' problem. The use of proprietary software may have some advantages for some people, but it does put users at the mercy of the only people who can fix or update that software: the software's owner. Most developers (most!) do not overtly wish to make life difficult for users of binary drivers. But asking them to go out of their way to shield binary driver users from the decisions made by their vendors is not just excessive; it actively risks making things worse for free software users.

Anybody who wants to criticize Fedora can certainly find any number of valid things to gripe about. Your editor would start with the two obnoxious PackageKit icons which materialized on the GNOME panel, and which, it seems, cannot be made to go away without the application of a fair amount of dynamite. Why does a Rawhide user need a constant reminder that there are updates available? But the failure to provide an NVIDIA-compatible X server does not seem like an appropriate thing to complain about. One should not blame Fedora for being free software.

Comments (23 posted)

Mozilla looks to simplify embedding

By Jake Edge
May 21, 2008

There has been a longstanding complaint about the difficulty in embedding Mozilla into other applications, but an effort is underway to change that. Mozilla evangelist Christopher Blizzard is coordinating a group of interested developers to redefine the application programming interfaces (APIs), libraries, and embedding "story" to try to make it easier for other applications. Mozilla is leading the way, but they want to build a community around embedding, so they are reaching out to developers that wish to help guide the effort.

Embedding the Gecko rendering engine—the guts of Mozilla's web content handling—will allow separate programs to deal with and use the web without writing the code themselves. New applications can leverage all of the work done by Mozilla to handle HTML, CSS, Javascript, etc. to concentrate on their specific task. There are several embedding use cases cited on the Mozilla wiki, but the focus of this new effort has been on applications where handling web content is just part of the task at hand.

To some extent, this effort is probably being driven by the rise of WebKit, which has a specific focus on being embeddable. WebKit is derived from the KHTML rendering engine—which underlies Konqueror—as modified by Apple for their Safari browser. There has been a fair amount of press about WebKit lately, which, along with the defection of the Epiphany browser from Gecko to WebKit, may have given Mozilla more motivation to make Gecko more embeddable.

Two meetings have occurred so far to discuss and plan a strategy for providing better embedding support. Blizzard has a lengthy report from the first which goes into some detail about the direction they are headed. The other was held in early May, but there are no reports from that as yet. This a young project that is looking for more interested folks to get involved.

One of the larger complaints about trying to embed Gecko into other applications is that there are multiple ways to do it. It is difficult for a developer to know which is right for their application. Blizzard says:

Sometimes you use libxul, sometimes you use the win32 embedding widget, sometimes you use the gtk embedding widget, sometimes you have to reach down into internal interfaces to change things and some times you don't. Having a single story around how to make use of the embedding APIs on your platform and in your environment is one of our goals.

Another area that needs work is providing a stable API. One of the downsides to not having stability at the API or application binary interface (ABI) is that security holes in Gecko tend to cascade throughout all the other applications that use it. But Blizzard does not expect to nail down the API right away:

So we will have some iteration during early development and will start locking things down once we have a better sense of what people [want] and what we'll need to change internally once we understand about our user's specific use cases. Stable API is a goal, but it's a longer goal. The more that we have people help us understand and contribute code out of the gate the faster we will get here.

[Embedded API diagram]

The diagram at right gives an overview of how the new API will fit. There is existing code at both the top and bottom of the diagram, while most the of the middle is new. Applications will be able to use some of the embedded functionality through platform-specific APIs—for GNOME, Windows, or OS X—or write directly to the new embedding APIs for more capabilities. One of the more interesting decisions is to use the existing APIs as a model, but not for creating a fully compatible implementation. Blizzard explains:

Note that trying to be a drop in replacement to WebKit or MSHTML/WebBrowser Control is not on the table. Therein lies madness. You end up chasing compatibility instead of just trying to make something that works really really well. But we can learn what works well from them and what doesn't and hopefully apply that to our new embedding interfaces.

The project has started on a roadmap of features that need to be worked on, beginning with the basics. Reorganizing the libraries and header files to create a software development kit (SDK) is high on that list. One of the bigger issues that needs to be addressed is how to handle profiles—the directory (i.e. $HOME/.mozilla) that Mozilla uses for user-specific data storage. Some use cases will want to run without a profile, but the current code expects to always have one available. The full list in the meeting report is worth a read.

This is an interesting project that should lead to more interesting applications down the road. The barriers to working with Gecko today are fairly high, but the advantages to using a well-tested, well-supported, and reasonably fast rendering engine for applications that need it are compelling. Those barriers look to be lowering in the not-too-distant future.

Comments (2 posted)

Debian contemplates patch management

By Jonathan Corbet
May 20, 2008
Developers in the Debian project had a busy week cleaning up after the openssl vulnerability was disclosed. Once that was taken care of, they moved on to process-related issues. Clearly, some shortcomings in how Debian handles patches to the programs it ships have been revealed; now the project would like to face those problems and make things work better in the future. The resulting discussion shows Debian at its introspective best, and may well have results that other distributors will want to pay attention to. As a Fedora developer noted: "This bug could easily have been us on the receiving end." All distributors make changes to their packages, so all of them are potentially exposed to this kind of failure.

Debian's packaging policy resembles that of most other distributions. A Debian source package is supposed to contain a tarball of the upstream source distribution, without changes. Any distribution-specific patches are included separately and applied when the source package is prepared for building. There are couple of Debian-specific issues to be faced, though:

  • From the discussion, it seems that the "pristine upstream tarball" rule is occasionally bent by developers. Sometimes there is no alternative: some upstream source distributions contain material which, due to its licensing, cannot be shipped by Debian. The justification for other cases is not always quite as clear.

  • Debian's patches are all mashed together and included as a single diff file. So there is no metadata describing the patches, and they are difficult to separate from each other. In this regard, Debian differs from RPM-based distributions, which generally keep each patch separate.

The end result of all this is that Debian's patches are hard for others to review, hard for upstream projects to consider, and even hard for other Debian developers to get a handle on.

Raphaël Hertzog started a discussion on how to improve this situation. A key part of his approach (and an idea which others have been pursuing as well) is to make changes to the Debian source package format which would make the nature of each patch explicit. At a minimum, packagers would include a debian/patches directory with the source; that directory would contain each patch, broken out into a separate file. Some Debian packages are built this way already, though the practice is far from universal.

Beyond that, though, it would be nice to have the source package itself understand the patch stream and its associated metadata. There are a few proposals for this; Raphaël favors the "3.0 (quilt)" format, which keeps the patches (in a separate tarball) as a quilt series. This format seems to have a certain amount of support; among other things, its simplicity would make it easy for Debian developers to create packages in this format without having to learn new tools. The quilt series file - like the spec file used with RPM packages - makes it clear which patches must be applied, and in which order.

There are other variants of the 3.0 source package format, though. The "3.0 (git)" format contains a git repository containing the upstream source and a series of patches to it. This approach has the advantage of including the history of the patches along with the other metadata; it could also, arguably, make it easier for other distributors (and upstream) to cherry-pick patches of interest. On the other hand, a git-based package format requires the availability of git and has the potential to make those packages larger. The GitSrc FAQ has some more information on this format; there's also a "3.0 (bzr)" format variant out there.

Any of these new formats, if widely adopted, would bring a new level of transparency to Debian's patching activities. It would enable the creation of a "patches.debian.org" site (clearly inspired by patches.ubuntu.com) where anybody could quickly look at the changes which have been made to any given package. There are some developers who doubt the utility of this; they worry that upstream developers won't want to poll a site to see what changes have been made to their code. One developer at least (GNOME hacker Vincent Untz) thinks that a patches.debian.org site would be a step in the right direction, though.

Another quibble which has been heard is that Debian does not need any new infrastructure for patch management. The right place for patch tracking, it is said, is with the upstream project. Nobody seems to challenge the claim that more patches need to go back upstream, but there is also the fact that quite a few patches will never get there. The upstream developers for a number of projects seem to have different goals and are seen by the distribution maintainers as being overtly uncooperative. And some patches - such as those removing non-free material - may not be something that even cooperative upstream maintainers want. So there will always be a need for distribution-specific patches; the "track it upstream" approach will not solve the whole problem.

Meanwhile, Joey Hess brought a completely different idea to the discussion: just treat every divergence from upstream as a bug. Each patch would have a corresponding entry in the Debian bug tracking system (BTS) with a special tag. Anybody could then query the list of outstanding bugs, view the patches, and participate in the associated discussion. Using the BTS brings some real technical advantages, in that the system already exists. But, Joey says, the real benefit is elsewhere:

The biggest reason for using the BTS is not technical. It's that, if we decide that the project will treat divergence from upstream as a bug, then we've effectively decided that maintainers will be responsible for both minimising unnecessary divergence, communicating about it to upstream, and for keeping track of what divergence exists. Because developers are responsible for their bugs.

A separate patch tracking mechanism, instead, would be a mostly automatic subsystem on the side which might not bring the same sort of pressure to bear on developers.

The BTS approach is not universally acclaimed either. Some developers claim that most Debian-specific patches are not really Debian bugs - they are, instead, upstream bugs. Regardless of whether that is really true, distribution bug trackers generally carry a great many entries which, in the end, describe bugs in upstream packages. Another complaint is that creating and maintaining BTS entries would be just another bit of bureaucratic work imposed on Debian developers. Beyond any doubt, some developers would see it that way.

But this may be a place where a bit more bureaucracy makes some sense. The Linux distributors of the world (certainly not just Debian) are carrying thousands of patches against the free programs they distribute. Making the nature and extent of those patches more readily apparent can only be beneficial for users, reviewers, distributors, and upstream maintainers. One clear conclusion from recent events is that all distributors could do more to let the rest of the community know about the changes they are making.

A distributor's ability to patch a program is a crucial part of the whole ecosystem - it's the distributors' way of balancing their users' needs against the upstream maintainer's policies. But distributors should be clear about the changes they are making, willing to merge those changes upstream whenever possible, and wanting feedback on those patches. Any "bureaucracy" which helps to make that happen can only help our community as a whole in ways that go far beyond the avoidance of another openssl disaster.

One final note: the existence of source package formats which incorporate distributed version control system repositories shows that developers have been thinking about this problem for a while; it's not just a response to recent events. There is an effort underway to think about what the intersection of version control and packaging can really achieve for all distributors; the folks working on this project can be found at vcs-pkg.org. They are working on organizing a gathering this September in Extremadura. Vcs-pkg is worth watching; it has the potential to make things work better for developers and users of all distributions.

Comments (31 posted)

Page editor: Jonathan Corbet

Security

Session cookies for web applications

By Jake Edge
May 21, 2008

Two weeks ago on this page, we reported on some Wordpress vulnerabilities that were caused by incorrectly generating authentication cookies. The article was a bit light on details about such cookies, so this follow-up hopes to remedy that. In addition, Steven Murdoch, who discovered both of the holes, recently presented a paper on a new cookie technique that provides some additional safeguards over other schemes.

HTTP is a stateless protocol which means that any application that wishes to track multiple requests as a single session must provide its own way to link those requests. This is typically done through cookies, which are opaque blobs of data that are stored by browsers. Cookies are sent to the browser as part of an HTTP response, usually after some kind of authentication is successful. The browser associates the cookie with the URL of the site so that it can send the cookie value back to the server on each subsequent request.

Servers can then use the value as a key into some kind of persistent storage so that all requests that contain that cookie value are treated as belonging to a particular session. In particular, it represents that the user associated with that session has correctly authenticated. The cookie lasts until it expires or is deleted by the user. When that happens, the user must re-authenticate to get a new cookie which also starts a new session. Users find this annoying if it happens too frequently, so expirations are often quite long.

If the user explicitly logs out of the application, any server-side resources that are being used to store state information can be freed, but that is often not the case. Users will generally just close their browser (or tab) while still being logged in. It is also convenient for users to be allowed multiple concurrent sessions, generally from multiple computers, which will cause the number of sessions stored to be larger, perhaps much larger, than the number of users.

Applications could restrict the number of sessions allowed by a user, or ratchet the expiration value way down, but they typically do not for user convenience. This allows for a potential denial of service when an attacker creates so many sessions that the server runs out of persistent storage. For this reason, stateless session cookies [PDF] were created.

Stateless session cookies store all of the state information in the cookie itself, so that the server need not keep anything in the database, filesystem, or memory. The data in the cookie must be encoded in such a way that they cannot be forged, otherwise attackers could create cookies that allow them access they should not have. This is essentially where Wordpress went wrong. By not implementing stateless session cookies correctly, a valid cookie for one user could be modified into a valid cookie for a different user.

A stateless session cookie has the state data and expiration "in the clear" followed by a secure hash (SHA-256 for example) of those same values along with a key known only by the server. When the server receives the cookie value, it can calculate the hash and if it matches, proceed to use the state information. Because the secret is not known, an attacker cannot create their own cookies with values of their choosing.

The other side of that coin is that an attacker can create spoofed cookies if they know the secret. Murdoch wanted to extend the concept such that even getting access to the secret, through a SQL injection or other web application flaw, would not feasibly allow an attacker to create a spoofed cookie. The result is hardened stateless session cookies [PDF].

The basic idea behind the scheme is to add an additional field to stateless session cookies that corresponds to an authenticator generated when an account is first set up. This authenticator is generated from the password at account creation by iteratively calculating the cryptographic hash of the password and a long salt value.

Salt is a random string—usually just a few characters long—that is added to a password before it gets hashed, then stored with the password in the clear. It is used to eliminate the use of rainbow tables to crack passwords. Hardened stateless session cookies use a 128-bit salt value, then repeatedly calculate HASH(prev|salt), where prev is the password the first time through and the hash value from the previous calculation on each subsequent iteration.

The number of iterations is large, 256 for example, but not a secret. Once that value is calculated, it is hashed one last time, without the salt, and then stored in the user table as the authenticator. When the cookie value is created after a successful authentication, only the output of the iterative hash itself is placed in the cookie, not the authenticator that is stored in the database. Cookie verification then must do the standard stateless session cookie hash verification, to ensure that the values have not been manipulated, then hash the value in the cookie to verify against authenticator in the database.

If it sounds complicated, it is; the performance of doing 256 hashes is also an issue, but it does protect against the secret key being lost. Because an attacker cannot calculate a valid authenticator value to put in the cookie (doing so would require breaking SHA-256), they cannot create their own spoofed cookies.

While it is not clear that the overhead of all of these hash calculations is warranted, it is an interesting extension to the stateless session cookie scheme. In his paper, Murdoch mentions some variations that could be used to further increase the security of the technique.

Comments (3 posted)

Brief items

Impact of the Debian OpenSSL vulnerability

CentOS looks at the impact of the Debian SSL vulnerability for CentOS users. "This vulnerability can affect CentOS machines through the use of keys that were generated with the OpenSSL package from Debian. For instance, if a user uses OpenSSH public key authentication to log on to a CentOS server, and this user generated the key pair with a vulnerable OpenSSL library, the server is at heavy risk because the key can be reproduced easily."

Full Story (comments: 26)

PayPal XSS Vulnerability Undermines EV SSL Security (Netcraft)

Netcraft is reporting a cross-site scripting (XSS) vulnerability at PayPal. Because PayPal uses the Extended Validation SSL certificate, the abuse potential is somewhat higher as we described in an article in March. "Harry Sintonen discovered the vulnerability and announced it to other web application security specialists in an Internet Relay Chat (IRC) channel today. Sintonen told Netcraft that the issue was critical, adding that, 'you could easily steal credentials,' and, 'PayPal says you can trust the URL if it begins with https://www.paypal.com,' which is not true in this case."

Comments (6 posted)

New vulnerabilities

Django: cross-site scripting

Package(s):Django CVE #(s):CVE-2008-2302
Created:May 21, 2008 Updated:May 21, 2008
Description: The Django administration application suffers from a cross-site scripting and JavaScript-injection vulnerability.
Alerts:
Fedora FEDORA-2008-4267 2008-05-21
Fedora FEDORA-2008-4248 2008-05-21
Fedora FEDORA-2008-4191 2008-05-21

Comments (none posted)

gnutls: several vulnerabilities

Package(s):gnutls CVE #(s):CVE-2008-1948 CVE-2008-1949 CVE-2008-1950
Created:May 20, 2008 Updated:September 17, 2008
Description: From the Red Hat advisory: Flaws were found in the way GnuTLS handles malicious client connections. A malicious remote client could send a specially crafted request to a service using GnuTLS that could cause the service to crash.
Alerts:
SuSE SUSE-SA:2008:046 2008-09-17
Slackware SSA:2008-180-01 2008-06-30
Mandriva MDVSA-2008:106 2007-05-23
rPath rPSA-2008-0174-1 2008-05-22
Gentoo 200805-20 2008-05-21
CentOS CESA-2008:0492 2008-05-22
Ubuntu USN-613-1 2008-05-21
CentOS CESA-2008:0489 2008-05-21
Fedora FEDORA-2008-4259 2008-05-21
Fedora FEDORA-2008-4183 2008-05-21
Fedora FEDORA-2008-4274 2008-05-21
Debian DSA-1581-1 2008-05-20
Red Hat RHSA-2008:0492-01 2008-05-20
Red Hat RHSA-2008:0489-01 2008-05-20

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):kernel CVE #(s):CVE-2008-2136 CVE-2008-2148
Created:May 15, 2008 Updated:January 8, 2009
Description: The kernel has several denial of service vulnerabilities. From the secunia report:

1) An error exists in the implementation of the "sys_utimensat()" system call. This can be exploited to update the access or modification time of arbitrary files via specially crafted arguments passed to the affected system call.

2) A memory leak exists in the "ipip6_rcv()" function included in the IPv6 over IPv4 (SIP) tunneling driver. This can be exploited to potentially exhaust all available memory via specially crafted network packets.

Alerts:
Red Hat RHSA-2008:0787-01 2009-01-05
CentOS CESA-2008:0973 2008-12-17
Red Hat RHSA-2008:0973-03 2008-12-16
Red Hat RHSA-2009:0001-01 2009-01-08
Red Hat RHSA-2008:0585-01 2008-08-26
Mandriva MDVSA-2008:167 2008-08-12
CentOS CESA-2008:0612 2008-08-06
Mandriva MDVSA-2008:174 2008-08-19
Red Hat RHSA-2008:0612-01 2008-08-04
Red Hat RHSA-2008:0607-01 2008-07-23
SuSE SUSE-SA:2008:032 2008-07-07
CentOS CESA-2008:0607 2008-07-24
Ubuntu USN-625-1 2008-07-15
SuSE SUSE-SA:2008:030 2008-06-20
Debian DSA-1588-2 2008-05-30
Debian DSA-1588-1 2008-05-27
rPath rPSA-2008-0169-1 2008-05-14

Comments (none posted)

kernel: denial of service

Package(s):kernel CVE #(s):CVE-2007-6282 CVE-2007-6712
Created:May 20, 2008 Updated:August 27, 2008
Description: From the Red Hat advisory: The possibility of a kernel crash was found in the Linux kernel IPsec protocol implementation, due to improper handling of fragmented ESP packets. When an attacker controlling an intermediate router fragmented these packets into very small pieces, it would cause a kernel crash on the receiving node during packet reassembly. (CVE-2007-6282) Also, on 64-bit architectures, the possibility of a timer-expiration value overflow was found in the Linux kernel high-resolution timers functionality, hrtimer. This could allow a local unprivileged user to setup a large interval value, forcing the timer expiry value to become negative, causing a denial of service (kernel hang). (CVE-2007-6712)
Alerts:
Red Hat RHSA-2008:0585-01 2008-08-26
Debian DSA-1630-1 2008-08-21
Ubuntu USN-625-1 2008-07-15
SuSE SUSE-SA:2008:032 2008-07-07
SuSE SUSE-SA:2008:031 2008-07-02
SuSE SUSE-SA:2008:030 2008-06-20
Debian DSA-1588-2 2008-05-30
Debian DSA-1588-1 2008-05-27
CentOS CESA-2008:0275 2008-05-21
Red Hat RHSA-2008:0275-01 2008-05-20

Comments (none posted)

libxslt: code execution

Package(s):libxslt CVE #(s):CVE-2008-1767
Created:May 21, 2008 Updated:August 1, 2008
Description: From the Red Hat advisory: Anthony de Almeida Lopes reported the libxslt library did not properly process long "transformation match" conditions in the XSL stylesheet files. An attacker could create a malicious XSL file that would cause a crash, or, possibly, execute and arbitrary code with the privileges of the application using libxslt library to perform XSL transformations.
Alerts:
Ubuntu USN-633-1 2008-08-01
Mandriva MDVSA-2008:151 2007-07-21
Slackware SSA:2008-210-03 2008-07-29
SuSE SUSE-SR:2008:013 2008-06-13
Gentoo 200806-02 2008-06-03
CentOS CESA-2008:0287 2008-05-21
Red Hat RHSA-2008:0287-01 2008-05-21

Comments (none posted)

peercast: buffer overflow

Package(s):peercast CVE #(s):CVE-2008-2040
Created:May 21, 2008 Updated:July 22, 2008
Description: The peercast streaming server suffers from a buffer overflow which can be exploited by a remote attacker.
Alerts:
Gentoo 200807-11 2008-07-21
Debian DSA-1583-1 2008-05-20
Debian DSA-1582-1 2008-05-20

Comments (none posted)

phpGedView: privilege escalation

Package(s):phpgedview CVE #(s):CVE-2008-2064
Created:May 20, 2008 Updated:May 21, 2008
Description: From the Debian advisory: It was discovered that phpGedView, an application to provide online access to genealogical data, allowed remote attackers to gain administrator privileges due to a programming error.
Alerts:
Debian DSA-1580-1 2008-05-20

Comments (none posted)

setroubleshoot: symlink and HTML injection vulnerabilities

Package(s):setroubleshoot CVE #(s):CVE-2007-5495 CVE-2007-5496
Created:May 21, 2008 Updated:May 21, 2008
Description: The setroubleshoot utility, used by system administrators to diagnose SELinux-related problems, suffers from symbolic link (file overwrite) and HTML injection vulnerabilities.
Alerts:
Red Hat RHSA-2008:0061-02 2008-05-21

Comments (none posted)

vsftpd: denial of service

Package(s):vsftpd CVE #(s):CVE-2007-5962
Created:May 21, 2008 Updated:June 6, 2008
Description: The vsftpd daemon suffers from a memory leak, leading to a denial of service vulnerability.
Alerts:
rPath rPSA-2008-0185-1 2008-06-05
Fedora FEDORA-2008-4373 2008-05-22
Fedora FEDORA-2008-4362 2008-05-22
Fedora FEDORA-2008-4347 2008-05-22
Red Hat RHSA-2008:0295-01 2008-05-21

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The current 2.6 development kernel is 2.6.26-rc3, released by Linus on May 18. Lots of fixes, of course, and things are stabilizing (though the list of regressions remains long). Linus also notes that the kernel developers have now been using git for as long as they used BitKeeper - but there's a lot more developers now. As always, the long-format changelog has the details.

As of this writing, almost 300 changesets have been merged into the mainline git repository since 2.6.26-rc3. They include a new test driver for MMC memory cards, a new device_create_drvdata() function (intended to fix a race condition caused by the previous separation of device_create() and dev_set_drvdata()), a USB wireless device management driver, and a lot of fixes.

The current stable 2.6 kernel is 2.6.25.4, released on May 15. It contains a fairly long list of fixes, a couple of which are security-related.

Comments (none posted)

Kernel development news

Quotes of the week

So you can either try to drink from the firehose and inevitably be bitched about because you're holding something up or not giving something the attention it deserves, or you can try to make sure that you can let others help you. And you'd better select the "let other people help you", because otherwise you _will_ burn out. It's not a matter of "if", but of "when".
-- Linus Torvalds on git workflows (worth reading in its entirety)

I have spoken with engineers both individual and within companies who have developed and who plan to develop substantial kernel features. I'm forever explaining to people why they should work to get that code merged up. One reason for their not yet having done so which comes up again and again is apprehension at the reception they will receive. In public. This problem appears to be especially strong in Asian countries. You have just made the situation worse.

But it's not just a self-interest thing. It is inevitably and unavoidably the case that when one senior kernel developer acts like an arrogant hostile dickhead, we will all be increasingly regarded as arrogant hostile dickheads.

-- Andrew Morton

I suppose alternately I could send another patch to remove "remember that ext3/4 by default offers higher data integrity guarantees than most." from Documentation/filesystems/ext4.txt ;)
-- Eric Sandeen

Comments (2 posted)

Appropriate sources of entropy

By Jake Edge
May 21, 2008

A steady stream of random events allows the kernel to keep its entropy pool stocked up, which in turn allows processes to use the strongest random numbers that Linux can provide. Exactly which events qualify as random—and just how much randomness they provide—is sometimes difficult to decide. A recent move to eliminate a source of contributions to the entropy pool has worried some, especially in the embedded community.

The kernel samples unpredictable events for use in generating random numbers, storing that data in the entropy pool. Entropy is a measure of the unpredictability or randomness of a data set, so the kernel estimates the amount of entropy each of those events contributes to the pool. Many kernels run on hardware that is lacking some of the traditional sources of entropy. In those cases, the timing of interrupts from network devices has been used as a source of entropy, but it has always been controversial, so it was recently proposed for removal.

Two of the best sources of random data for the entropy pool—user interaction via a keyboard or mouse and disk interrupts—are often not present in embedded devices. In addition, some disk interfaces, notably ATA, do not add entropy, which extends the problem to many "headless" servers. But network interrupts are seen as a dubious source of entropy because they may be able to be observed, or manipulated, by an attacker. In addition, as network traffic rises, many network drivers turn off receive interrupts from the hardware, allowing the kernel to poll periodically for incoming packets. This would reduce entropy collection just at the time when it might be needed for encrypting the traffic.

This is not the first time eliminating the IRQF_SAMPLE_RANDOM flag from network drivers has come up; we looked at the issue two years ago (though the flag was called SA_SAMPLE_RANDOM at that time). It has come up again, starting with a query on linux-kernel from Chris Peterson: "Should network devices be allowed to contribute entropy to /dev/random?" Jeff Garzik, kernel network device driver maintainer, answered: "I tend to push people to /not/ add IRQF_SAMPLE_RANDOM to new drivers, but I'm not interested in going on a pogrom with existing code."

For anyone that is interested in such a pogrom, Peterson proposed a patch to eliminate the flag from the twelve network drivers that still use it. This sparked a long discussion on how to provide entropy for those devices that do not have anything else to use. While the actual contribution of entropy from network devices is questionable, mixing that data into the pool does not harm it, as long as no entropy credit—the current estimate of entropy in the pool—is awarded. Alan Cox proposed a new flag to track sources like that:

A more interesting alternative might be to mark things like network drivers with a new flag say IRQF_SAMPLE_DUBIOUS so that users can be given a switch to enable/disable their use depending upon the environment.

Some were in favor of an approach like this, but Adrian Bunk notes that:

If he can live with dubious data he can simply use /dev/urandom .

If a customer wants to use /dev/random and demands to get dubious data there if nothing better is available fulfilling his wish only moves the security bug from his crappy application to the Linux kernel.

Part of the problem stems from a misconception about random numbers gotten from /dev/random versus those that are read from /dev/urandom, which we described in a Security page article last December. In general, applications should read from /dev/urandom. Only the most sensitive uses of random numbers—keys for GPG for example—need the entropy guarantee that /dev/random provides. In a system that is getting regular entropy updates, the quality of the random numbers from both sources is the same.

There is still an initialization problem for some systems, though, as Ted Ts'o points out:

Hence, if you don't think the system hasn't run long enough to collect significant entropy, you need to distinguish between "has run long enough to collect entropy which is causes the entropy credits using a somewhat estimation system where we try to be conservative such that /dev/random will let you extract the number of bits you need", and "has run long enough to collect entropy which is unpredictable by an outside attacker such that host keys generated by /dev/urandom really are secure".

A potential entropy source, even for embedded systems, is to sample other kernel and system parameters that are not predictable externally. Garzik suggests:

EGD demonstrates this, for example: http://egd.sourceforge.net/ It looks at snmp, w, last, uptime, iostats, vmstats, etc.

And there are plenty of untapped entropy sources even so, such as reading temperature sensors, fan speed sensors on variable-speed fans, etc.

Heck, "smartctl -d ata -a /dev/FOO" produces output that could be hashed and added as entropy.

Another source is from hardware random number generators. The kernel already has support for some, including the VIA Padlock that seems to be well thought of. Not all processors have such support, however. The Trusted Platform Module (TPM) does have random number generation and is becoming more widespread, especially in laptops, but there is no kernel hw_random driver for TPM.

Garzik advocates adding a kernel driver for what he calls the "Treacherous Platform Module", but as others pointed out, it can all be done in user space using the TrouSerS library. Even for the hardware random number generators that are supported in the kernel there is no automatic entropy collection, as it is left up to user space to decide whether to do that. This is done to try and keep policy decisions about the quality of the random data out of kernel code.

Systems that wish to sample that data should use rngd to feed the kernel entropy pool. rngd will apply FIPS 140-2 tests to verify the randomness of the data before passing it to the kernel. Andi Kleen is not in favor of that approach:

Just think a little bit: system has no randomness source except the hardware RNG. you do your strange randomness verification. if it fails what do you do? You don't feed anything into your entropy pool and all your random output is predictable (just boot time) If you add anything predictable from another source it's still predictable, no difference.

There is concern that some of the hardware random number generators are poorly implemented or could malfunction, so it would be dangerous to automatically add that data into the pool. Doing the FIPS testing in the kernel is not an option, leaving it up to user space applications to make the decision. There is nothing stopping any superuser process from adding bits to the entropy pool—no matter how weak—but the consensus is that the kernel itself must use sources it knows it can trust.

Another instance of this problem—in a different guise—appears in a discussion about random numbers for virtualized I/O, with Garzik asking: "Has anyone yet written a "hw" RNG module for virt, that reads the host's random number pool?" Rusty Russell responded with a patch for a virtio "hardware" random number generator as well as one that adds it into his lguest hypervisor. The lguest patch reads data from the host's /dev/urandom, which is not where H. Peter Anvin thinks it should come from:

There is no point in feeding the host /dev/urandom to the guest (except for seeding, which can be handled through other means); it will do its own mixing anyway. The reason to provide anything at all from the host is to give it "golden" entropy bits.

The virtio implementation only provides the hw_random implementation, thus it requires user space help to get entropy data into the kernel. Much like any process that can read /dev/random, lguest could exhaust the host entropy pool, so there was some discussion of limiting how much random data guests can request from the device. A guest implementation could then use a small pool of entropy read from the host to seed its own random number generator for the simulated hardware device.

Removing the last remaining uses of IRQF_SAMPLE_RANDOM in network drivers seems likely, though some way to mix that data into the entropy pool without giving it any credit is still a possibility. With luck, that will encourage more effort into incorporating new sources of entropy using tools like EGD or, for systems that have it available, random number hardware. For systems that lack the traditional entropy sources, this should lead to a better initialized and fuller pool, while eliminating a potential attack by way of network packet manipulation.

Comments (32 posted)

Kill BKL Vol. 2

By Jonathan Corbet
May 21, 2008
Last week's big kernel lock article discussed a BKL-related performance regression and concluded that we would likely see a new interest in its elimination. In the intervening week, that interest has indeed come to the fore. There are now a couple of different efforts afoot to get rid of this long-lasting lock.

One might well wonder why the BKL is so persistent. Over the last (approximately) fifteen years, thousands of locks have been added to the kernel, pushing the BKL into increasingly obscure corners. But there are a lot of those corners, including a great many explicit lock_kernel() calls, the open() method for every char device, most ioctl() implementations, all fasync() implementations, and more. The BKL can be found throughout the kernel, and doesn't appear ready to go without a fight.

Part of the problem is simply that locking is hard. So going in and changing the locking of some crufty, old driver is not at the top of the list for a lot of developers, who would generally rather be creating crufty new drivers. Beyond that, though, the BKL is special. It was originally created to be more than just a locking primitive; its purpose is to allow BKL-covered code to pretend that it is still running on an old, uniprocessor system. So its semantics are very different from any other lock in the Linux kernel.

For example, the BKL nests, so programmers can add lock_kernel() calls anywhere without worrying about whether the BKL might already have been acquired elsewhere. As with a mutex, code holding the BKL can sleep; however, the scheduler will magically release the BKL until the holding thread wakes up again. So there can be various threads in kernel space, all of which think they hold the BKL, but only one of them will actually be running at any given time. The end result is that it is hard to get a handle on what is happening with the BKL at any given time; code can depend on it without ever really being aware of its existence.

As Ingo Molnar put it in his kill the BKL tree announcement:

Furthermore, the BKL is not covered by lockdep, so its dependencies are largely unknown and invisible, and it is all lost in the haze of the past ~15 years of code changes. All this has built up to a kind of Fear, Uncertainty and Doubt about the BKL: nobody really knows it, nobody really dares to touch it and code can break silently and subtly if BKL locking is wrong.

That doesn't mean that people aren't willing to try; Ingo's tree - to which we will return shortly - is a major effort in that direction. But first, consider another initiative which, somewhat accidentally, turned up an example of just how subtle BKL-related issues can be. As was mentioned above, the kernel grabs the BKL whenever a process opens a char device; the BKL is held while the associated driver's open() function runs. To eliminate BKL, one must remove this particular use of it; one cannot just take it out, however, without breaking every driver which does not have proper locking internally. So, in fact, this lock_kernel() call cannot be removed until every driver's open() function has been audited and, if necessary, fixed. That's a big flag day.

An alternative, which your editor rashly jumped into doing, is to push the acquisition of the BKL down one level. Every open() function is forced to be correct through the addition of explicit lock_kernel() and unlock_kernel() calls; once all of the in-tree drivers have been fixed in this way, the higher-level call in chrdev_open() can be removed. This work may seem like a step backward, in that it replaces a single lock_kernel() call with approximately 100 others. But it's actually a big step forward, in that each driver can now be audited and fixed independently. This work has now been done, the resulting tree is in linux-next, and, if all goes well, it should be ready for 2.6.27.

While doing this work, though, your editor noticed quite a few drivers with open functions that were either completely empty (all they do is "return 0") or they do something relatively trivial. These functions, one would think, do not need to acquire the BKL; they touch no global resources and cannot possibly race with any other part of the kernel. In fact, as was suggested by others, the empty open() functions could just be removed altogether.

It was Alan Cox who pointed out that life is not quite so simple. Under the current regime, an open function which looks like this:

    static int empty_open(struct inode *inode, struct file *filp)
    {
    	return 0;
    }

is really better modeled as this:

    static int empty_open(struct inode *inode, struct file *filp)
    {
        lock_kernel();
	unlock_kernel();
    	return 0;
    }

These two may seem the same, but there is a crucial difference: in the second form, empty_open() will not return until it can acquire the BKL. In other words, after empty_open() runs, one knows that the BKL became available at least once. And this matters: a classic device driver error is to (1) register a device with the kernel, then (2) initialize all of the internal data structures needed to manage that device. Should some other process attempt to open and use the device between those two steps, unpleasant things can happen. The lock_kernel() call in the open() function, despite protecting no critical section directly, serializes the opening of the device with the driver's initialization, and thus prevents mayhem. So, says Alan,

I think it would be best to make them lock/unlock kernel in the first pass and then work through them. The BKL can be subtle and evil, but as I brought it into the world I guess I must banish it ;)

Alan will not be alone in that effort, though, and Ingo Molnar's "kill the BKL" tree is likely to help this work considerably. Ingo's approach is to get rid of most of the features which make the BKL special. So, with his patches, the BKL becomes just another mutex which, crucially, can be tracked with the lock validator. It is no longer released when a thread calls schedule(), a change which forced the addition of a few explicit "release, schedule, and reacquire" changes in code which would otherwise deadlock. There's a number of warnings added to point out calls made holding the BKL which should not be. And so on.

This patch set, in essence, removes the BKL entirely, replacing it with just another big lock which happens to do nesting. And the nesting might go too at some point. So the BKL becomes more visible and easier to understand. And, presumably, easier to eliminate.

Linus likes this approach, though he would like to see it reworked to the point that it can be merged into the mainline relatively soon. Doing that would require putting most of the changes behind a configuration option decorated with a sufficient number of scary warnings; then people who wanted to test this code could turn it on and see what explodes. The number of explosions would probably be relatively small - but probably not zero.

This set of changes, along with the other work being done, suggests that significant progress toward the elimination of the BKL can be expected over the next few kernel development cycles. Once it's gone, we'll have a kernel without legacy locking issues, and without the unpleasant performance issues that the BKL can bring. That will still take a while, though; there is simply no substitute for actually looking at all the BKL-covered code and ensuring that it will run safely in the absence of that protection. It's a painstaking job requiring moderate skills which can only be rushed so much.

Comments (2 posted)

Barriers and journaling filesystems

By Jonathan Corbet
May 21, 2008
Journaling filesystems come with a big promise: they free system administrators from the need to worry about disk corruption resulting from system crashes. It is, in fact, not even necessary to run a filesystem integrity checker in such situations. The real world, of course, is a little messier than that. As a recent discussion shows, it may be even messier than many of us thought, with the integrity promises of journaling filesystems being traded off against performance.

A filesystem like ext3 works by maintaining a journal on a dedicated portion of the disk. Whenever a set of filesystem metadata changes are to be made, they are first written to the journal - without changing the rest of the filesystem. Once all of those changes have been journaled, a "commit record" is added to the journal to indicate that everything else there is valid. Only after the journal transaction has been committed in this fashion can the kernel do the real metadata writes at its leisure; should the system crash in the middle, the information needed to safely finish the job can be found in the journal. There will be no filesystem corruption caused by a partial metadata update.

There is a hitch, though: the filesystem code must, before writing the commit record, be absolutely sure that all of the transaction's information has made it to the journal. Just doing the writes in the proper order is insufficient; contemporary drives maintain large internal caches and will reorder operations for better performance. So the filesystem must explicitly instruct the disk to get all of the journal data onto the media before writing the commit record; if the commit record gets written first, the journal may be corrupted. The kernel's block I/O subsystem makes this capability available through the use of barriers; in essence, a barrier forbids the writing of any blocks after the barrier until all blocks written before the barrier are committed to the media. By using barriers, filesystems can make sure that their on-disk structures remain consistent at all times.

There is another hitch: the ext3 and ext4 filesystems, by default, do not use barriers. The option is there, but, unless the administrator has explicitly requested the use of barriers, these filesystems operate without them - though some distributions (notably SUSE) change that default. Eric Sandeen recently decided that this was not the best situation, so he submitted a patch changing the default for ext3 and ext4. That's when the discussion started.

Andrew Morton's response tells a lot about why this default is set the way it is:

Last time this came up lots of workloads slowed down by 30% so I dropped the patches in horror. I just don't think we can quietly go and slow everyone's machines down by this much...

There are no happy solutions here, and I'm inclined to let this dog remain asleep and continue to leave it up to distributors to decide what their default should be.

So barriers are disabled by default because they have a serious impact on performance. And, beyond that, the fact is that people get away with running their filesystems without using barriers. Reports of ext3 filesystem corruption are few and far between.

It turns out that the "getting away with it" factor is not just luck. Ted Ts'o explains what's going on: the journal on ext3/ext4 filesystems is normally contiguous on the physical media. The filesystem code tries to create it that way, and, since the journal is normally created at the same time as the filesystem itself, contiguous space is easy to come by. Keeping the journal together will be good for performance, but it also helps to prevent reordering. In normal usage, the commit record will land on the block just after the rest of the journal data, so there is no reason for the drive to reorder things. The commit record will naturally be written just after all of the other journal log data has made it to the media.

That said, nobody is foolish enough to claim that things will always happen that way. Disk drives have a certain well-documented tendency to stop cooperating at inopportune times. Beyond that, the journal is essentially a circular buffer; when a transaction wraps off the end, the commit record may be on an earlier block than some of the journal data. And so on. So the potential for corruption is always there; in fact, Chris Mason has a torture-test program which can make it happen fairly reliably. There can be no doubt that running without barriers is less safe than using them.

Anybody can turn on barriers if they are willing to take the performance hit. Unless, of course, their filesystem is based on an LVM volume (as certain distributions do by default); it turns out that the device mapper code does not pass through or honor barriers. But, for everybody else, it would be nice if that performance cost could be reduced somewhat. And it seems that might be possible.

The current ext3 code - when barriers are enabled - performs a sequence of operations like this for each transaction:

  1. The log blocks are written to the journal.
  2. A barrier operation is performed.
  3. The commit record is written.
  4. Another barrier is executed.
  5. Metadata writes begin at some later point.

On ext4, the first barrier (step 2) can be omitted because the ext4 filesystem supports checksums on the journal. If the journal log data and the commit record are reordered, and if the operation is interrupted by a crash, the journal's checksum will not match the one stored in the commit record and the transaction will be discarded. Chris Mason suggests that it would be "mostly safe" to omit that barrier with ext3 as well, with a possible exception when the journal wraps around.

Another idea for making things faster is to defer barrier operations when possible. If there is no pressing need to flush things out, a few transactions can be built up in the journal and all shoved out with a single barrier. There is also some potential for improvement by carefully ordering operations so that barriers (which are normally implemented as "flush all outstanding operations to media" requests) do not force the writing of blocks which do not have specific ordering requirements.

In summary: it looks like the time has come to figure out how to make the cost of barriers palatable. Ted Ts'o seems to feel that way:

I think we have to enable barriers for ext3/4, and then work to improve the overhead in ext4/jbd2. It's probably true that the vast majority of systems don't run under conditions similar to what Chris used to demonstrate the problem, but the default has to be filesystem safety.

Your editor's sense is that this particular dog is now wide awake and is likely to bark for some time. That may disturb some of the neighbors, but it's better than letting somebody get bitten later on.

Comments (63 posted)

Patches and updates

Kernel trees

Core kernel code

Development tools

Device drivers

Filesystems and block I/O

Janitorial

Memory management

Networking

Architecture-specific

Security-related

Virtualization and containers

Benchmarks and bugs

Miscellaneous

Page editor: Jonathan Corbet

Distributions

News and Editorials

Exherbo announced. Sort of...

By Rebecca Sobol
May 21, 2008

A new distribution called Exherbo has announced its existence. It's at least partly inspired by Gentoo and has borrowed some Gentoo code.

Exherbo is not a Gentoo fork in the conventional sense. Although it shares some code with Gentoo, and although many concepts are similar, and although many of the people involved were or are Gentoo developers, most Exherbo code is rewritten from scratch.

Exherbo is not your average distribution, nor does it aspire to be. In fact, Exherbo is not for users at all. Exherbo is designed to be a developer's playground. A place to experiment, to innovate, and to break packages with impunity.

So far there isn't much there. The projects page lists only two projects so far: Arbor, an exheres-format (the Exherbo package format) repository for base system and assorted useful packages, and Genesis, which aims to be a replacement init daemon.

There are two mailing lists available, the main development list and a commit mailing list. The source repository has some packages in git and a few more in subversion. There's a Bugzilla bug tracker too. So there isn't much yet, but the infrastructure is there to support what may come.

Perhaps the most interesting part of the site for most people is the Planet Exherbo, a typical blog space for developers to talk about what they are doing, or would like to do, or whatever. For example you'll find this post [warning, site is currently reported by Firefox 3 as an "Attack Site", content can also be found on the Planet site] by Anders Ossowicki which explains:

First of all, Exherbo was announced because some elements of it will be discussed at an upcoming conference. Rather than having a blank page and let people start various rumors it seemed wise to at least let people know what was going on. But in an effort not to hype it above what it was, we didn't hand over all available information and code.

Unfortunately Slashdot picked up the announcement because some tard decided it would be a great idea to submit it to them. We did not do that ourselves because, as we state on the website, we have no need for users at the moment and exherbo won't fulfill users demands for the foreseeable future. That is not to say exherbo won't ever become useful but we're not there at the moment. Some very basic things still need to be worked out properly.

So there it is. Do not download and expect a working distribution. Do not expect a release of a working distribution any time soon. But if you are a developer with an itch to scratch, this might be the place to so. Just to keep it all together, here's the original LWN announcement and all associated comments.

Comments (2 posted)

New Releases

rPath Linux 2.0 available

rPath has announced that rPath Linux 2 is now available. "rPath Linux is a base operating system platform on which you easily build customized virtual or software appliances, or even an entire operating system of your own. Building on the rPath Linux foundation, use rPath's tools to create and maintain your own minimal operating system stack, with "Just Enough OS" to support the applications and services you include."

Full Story (comments: none)

Novell Delivers SUSE Linux Enterprise 10 Enhancements in Service Pack 2

Novell has announced the availability to customers worldwide of SUSE Linux Enterprise 10 Service Pack 2 (SP2). With this release SP1 goes into a 6-month maintenance period.

Comments (none posted)

Announcing openSUSE 11.0 Beta 3

The third beta of openSUSE 11.0 is available. "Over 700 bugs were fixed since beta 2, more new artwork was added and several new package versions were includes. The live installation has seen great improvements and should work flawless now."

Full Story (comments: none)

Fedora 9 Everything Spin released

Fedora Unity has announced the release of the Fedora 9 Everything Spin, for those who want it all. The Everything Spin includes everything available at the time of the release of Fedora 9.

Full Story (comments: 1)

Distribution News

Debian GNU/Linux

Bits from the DPL

In this edition of Bits from the DPL (dated May 15th), Steve McIntyre points to several interviews, recent delegations, team reviews, Summer of Code 2008, DebConf, Lenny, and openssl. Click below for all the bits.

Full Story (comments: none)

Perl 5.10 transition: Done

The Perl5.10 transition has now been completed, with about 400 source packages in testing getting updates. "Please also note that this new perl version is the last major update to the Debian toolchain for lenny."

Full Story (comments: none)

Fedora

Cooperative Bug Isolation for Fedora 9

The Cooperative Bug Isolation Project (CBI) is now available for Fedora 9. CBI is an ongoing research effort to find and fix bugs in the real world. "We distribute specially modified versions of popular open source software packages. These special versions monitor their own behavior while they run, and report back how they work (or how they fail to work) in the hands of real users like you. Even if you've never written a line of code in your life, you can help make things better for everyone simply by using our special bug-hunting packages."

Full Story (comments: none)

Gentoo Linux

Gentoo Foundation officially reinstated by New Mexico

The Gentoo Foundation has been reinstated and returned to good standing by the state of New Mexico, USA. "This accomplishment allows other aspects of the foundation's work to proceed again. The foundation takes care of Gentoo's intellectual property (copyrights, trademarks) and money. It ensures that nobody violates our copyrights and trademarks, serves as a place to hold money, and decides where to devote that money."

Comments (none posted)

New Distributions

GKLinuxOS 2008

GKLinuxOS is based on PCLinuxOS 2007 and comes with lots of applications including OpenOffice.org and other office software, graphics and drawing, multimedia audio-video programs, programs for web-browsing, email and chat, and much more. GKLinuxOS 2008 with KDE 3.5.x is available.

Comments (none posted)

Distribution Newsletters

Ubuntu Weekly Newsletter #91

The Ubuntu Weekly Newsletter for May 17, 2008 covers the OpenSSL/OpenSSH vulnerability, FOSSCamp 2008 Prague, The Art of Release(Mark Shuttleworth), 5-a-day and Loco teams, Linux distro Smack Down(Podcast), Metalinks, what are those?, Ubuntu on Berlin metro system, Ubuntu featured in Vermist(Movie), and much more.

Full Story (comments: none)

OpenSUSE Weekly News/22

This edition of OpenSUSE Weekly News covers Linuxtag 2008 - latest information, People of openSUSE: Marcus Hüwe, and much more.

Comments (none posted)

DistroWatch Weekly, Issue 253

The DistroWatch Weekly for May 19, 2008 is out. "Fedora 9 came out last week as expected, but the many experimental features and software packages in the distribution seem to detract some would-be users from upgrading their distribution. Do you enjoy testing the latest and greatest the Linux development world has to offer? Then Fedora 9 is for you. Otherwise look elsewhere. In the news section, Ubuntu's Mark Shuttleworth calls on greater release synchronisation between the major Linux vendors, Debian struggles to come to terms with a massive OpenSSL vulnerability, ComputerWold Australia interviews Ian Murdock, the Sun Microsystems' vice president in charge of OpenSolaris, and Gentoo succeeds in reinstating Gentoo Foundation in New Mexico. Also in this issue, an explanation why DistroWatch does not focus more on GPL violations and other legal topics, and an opinion piece on the subject of growing mistrust of users towards Canonical and Ubuntu."

Comments (none posted)

Distribution meetings

Ubuntu Live 2008 canceled

Ubuntu Live 2008, originally scheduled for July 21-22, 2008, has been canceled. "We are planning to include some Ubuntu content in the O'Reilly Open Source Convention (OSCON), also happening July 21-25 in Portland, Oregon."

Comments (none posted)

Newsletters and articles of interest

A review of rPath Linux 2.0 (LinuxDevices)

LinuxDevices has a brief overview and review of rPath Linux 2.0. "rPath Linux is a specialized Linux distribution designed for use by ISVs (independent software vendors) wishing to deliver their products as pre-installed hardware appliances, or as 'software appliances.' The latter are pre-configured Linux server stacks suitable for installation by users on real or virtual commodity hardware."

Comments (8 posted)

Distribution reviews

Ubuntu - 8.04 (Review) (techpark6.com)

techpark6.com has a review of Ubuntu 8.04. "With such an expansive operating system like Ubuntu 8.04 you'll likely encounter the gamut of opinions ranging from praise to unsatisfied complaints. Having used Ubuntu 8.04 since the early alpha testing period, I can say that I find Ubuntu 8.04 to be one of the more (if not the most) polished and ready for widespread use Linux operating systems made to date."

Comments (none posted)

Page editor: Rebecca Sobol

Development

Use Rakarrack for Electric Guitar Effects

By Forrest Cook
May 21, 2008

Rakarrack is a new GUI-based application that can turn a Linux machine into a collection of audio effects for use in the making of music. The developers include Josep Andreu, Daniel Vidal and Hernán Ordiales with help from other individuals. Rakarrack version 0.1.2 was recently announced, it appears to be the first public release. From the project's web page:

[Rakarrac]

Rakarrack is a guitar effects processor for GNU / Linux simple and easy to use but it contains features that make it unique in this field of applications. It contains 10 effects: Linear Equalizer, Parametric Equalizer, Compressor, Distorsion, Overdrive, Echo, Chorus, Phaser, Flanger and Reverb. It integrates a tuner and a MIDI converter (experimental). It can also be handled by an external MIDI controller. The settings designed by the user can be stored in presets and these presets can be used to create banks of effects.

The README file in the source code has some information on the motivation behind the project: "This app born after an informal conversation about effects for guitar over GNU/linux. The major part of this apps are discontinued or simply not have new versions after few years. Josep Andreu say on the IRC chat "I can made an app based on the effects set hid[d]en on code of ZynAddSubFX (by Paul Nasca Octavian). Some time after here is the result of our work..."

The project screen shots show the GUI layout and various color schemes. Compared to a typical hardware audio processor, the GUI has big advantages over the usual LCD display that most effect units have. One need not hunt around a pushbutton-controlled memory to view and change the many adjustable parameters and the system disk provides nearly unlimited configuration storage possibilities. To hear Rakarrac in action, listen to the demo by Carlos Pino (ogg format).

One might wonder if audio effects processors will soon follow mobile phones, TiVo-like video recorders and consumer-based audio recorders in the transition from proprietary operating systems to Linux-based embedded systems. Such a system could be put together with a small Linux-compatible embedded platform, an LCD interface such as LCDproc (with the aforementioned UI limitations), keyboard and audio interfaces and some DSP software similar to Rakarrac. In the mean time, if you have a need for a versatile hardware effector and can spare some CPU cycles, Rakarrac may be an effective solution. The software is available for download here.

Comments (5 posted)

System Applications

Database Software

PostgreSQL Weekly News

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

Full Story (comments: none)

Device Drivers

ALE Server: 1.2.2 Released (SourceForge)

Version 1.2.2 of ALE Server, an RFID-EPC compliant RFID middleware package, has been announced. "The staff at logicAlloy is pleased to announce a new release of ALE Server, our open source RFID middleware. This new version has bug fixes related to the default password and linux distributions."

Comments (none posted)

DNS Software

Unbound 1.0 released

Some projects send out an email to announce a release; others opt for press releases. Here is the press release for Unbound 1.0, a new, BSD-licensed domain name server intended to compete with Bind. "Although BIND has been the de facto choice for DNS servers since the 1980s, a desire to seek an alternative server that excels in security, performance and ease of use prompted an effort to develop an open source DNS implementation. Unbound is the result of that effort."

Comments (13 posted)

Interoperability

Samba Mashup Report

Edition number two of the Samba Mashup Report has been announced. "Table of Contents: 1. Samba 3.2.0 Moves closer to Release 2. Bug fix release for Samba 3.0 in the works 3. Developer Interests - Volker Lendecke 4. Samba at Connectathon 5. Samba4 - Fact or Fantasy? 6. Call for submissions and summaries"

Comments (none posted)

Networking Tools

nfsreplay: version 0.0.2 released (SourceForge)

Version 0.0.2 of nfsreplay has been announced. "nfsreplay is a tool to replay Network File System traffic. It can be used for server and client benchmarking under a wide range of workloads. It allows temporal and spatial scaling of the original trace."

Comments (none posted)

Putty Terminal Deployer: initial release (SourceForge)

The initial release of Putty Terminal Deployer has been announced. "PuTTY Terminal Deployer allows dynamic PuTTY secure shell (SSH) logins to multiple Linux servers. Host, IP addresses and AES encrypted/Base64 encoded passwords are read from a configuration file. All GUI labels are created dynamically from this info."

Comments (none posted)

pyftpdlib 0.4.0 released

Version 0.4.0 of pyftpdlib has been announced. "Python FTP server library provides an high-level portable interface to easily write asynchronous FTP servers with Python. Based on asyncore framework pyftpdlib is currently the most complete RFC-959 FTP server implementation available for Python programming language. This new version, aside from fixing some bugs, includes two new features: - IPv6 support (as described in RFC-2428). - The possibility to assume the id of real users when using system dependent authorizers."

Full Story (comments: none)

Peer to Peer

DistrPeer: Version 0.0.2 released (SourceForge)

Version 0.0.2 of DistrPeer has been announced. "DistrPeer is a client to p2p network without any hubs and trackers, in other words, fully decentralized. Each file before sharing is encoded and splitted for keeping in several computers what provide redundant and distributed storing of files."

Comments (none posted)

Web Site Development

Django security fix released

A new security fix release of the Django web platform has been announced. "The Django administration application will, when accessed by a user who is not sufficiently authenticated, display a login form and ask the user to provide the necessary credentials before displaying the requested page. This form will be submitted to the URL the user attempted to access, by supplying the current request path as the value of the form's "action" attribute. The value of the request path was not being escaped, creating an opportunity for a cross-site scripting (XSS) attack by leading a user to a URL which contained URL-encoded HTML and/or JavaScript in the request path."

Comments (none posted)

Miscellaneous

OpenPanel: 0.9.2 released (SourceForge)

Version 0.9.2 of OpenPanel has been announced. "OpenPanel is a remote server administration and configuration system for Unix-based systems. It offers both an AJAX Web interface and a CLI which allow you to manage users, domains, email, and other hosting-related services. Added configurable AXFR restrictions for DNS. Fixed handling of MySQL users, hosts and privileges. Fixed handling of Postfix aliases and catch-all forwards. Cleaned up lots of post-installation issues and stray dependencies."

Comments (none posted)

Desktop Applications

Audio Applications

NASPRO 0.1.0 released

Version 0.1.0 of NASPRO has been announced. "NASPRO is a free, powerful, reusable, modular, real-time capable, thread-safe, scalable, standard-agnostic, cross-platform framework for digital signal processing, especially focused on sound processing. Its main aim is to give audio application developers a full-featured, yet scalable, high-performance and integrated tool to make use of virtually any external sound processing component (including, but not limited to, LADSPA/DSSI, LV2, VST, AudioUnits and DirectX plugins) via a single, fully transparent and platform-independent API."

Full Story (comments: none)

Desktop Environments

GNOME 2.23.2 released

Version 2.23.2 of the GNOME desktop environment has been released. "We start the 2.23 development cycle only a few weeks ago, and some results are already appearing here and there. By results, I mean new features, new bugs fixes, and also cool new bugs :-) I'd love to see even more new bugs -- reporting them would help me with my bugzilla points, but it seems GNOME contributors have this habit of keeping things stable. Oh, well."

Full Story (comments: none)

GARNOME 2.23.2 released

Version 2.23.2 of GARNOME, the bleeding edge GNOME distribution, is out. "The "Music for the Maases" release. Hope you enjoy the ride. We are pleased to announce the release of GARNOME 2.23.2 Desktop and Developer Platform. This is the second development release on our trip to GNOME 2.24, which will be out in September."

Full Story (comments: none)

GNOME Software Announcements

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

Comments (none posted)

KDE Software Announcements

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

Comments (none posted)

Desktop Publishing

pdfposter 0.4 announced

Version 0.4 of pdfposter is available. "``Pdfposter`` can be used to create a large poster by building it from mult[i]ple pages and/or printing it on large media. It expects as input a PDF file, normally printing on a single page. The output is again a PDF file, maybe containing multiple pages together building the poster. The input page will be scaled to obtain the desired size. This is much like ``poster`` does for Postscript files, but working with PDF."

Full Story (comments: none)

Interoperability

Wine 1.0-rc1 released

Version 1.0-rc1 of Wine has been announced. Changes include: Bug fixes only, we are in code freeze.

Comments (none posted)

Music Applications

jack-keyboard 2.5 announced

Version 2.5 of jack-keyboard is available. "The biggest change is switching from hand-written makefiles to autotools. This should make packagers' life easier. jack-keyboard is a virtual MIDI keyboard - a program that allows you to send JACK MIDI events (play ;-) using your PC keyboard."

Full Story (comments: none)

jack-smf-utils 1.0 released

Version 1.0 jack-smf-utils of has been announced. "Jack-smf-utils is a set of two command line utilities - jack-smf-player and jack-smf-recorder - whose purpose is to play and record MIDI streams from/to Standard Midi Files (i.e. the files with .mid extension) using JACK MIDI."

Full Story (comments: none)

ll-plugins 0.2.0 released

Version 0.2.0 of ll-plugins, a collection of LV2 plugins, has been announced. "The plugins are reasonably simple and could be used as examples or starting points for hackers who want to write LV2 plugins based on the frameworks in the lv2-c++-tools package. There are synths, event processors, simple audio and control manipulators and GUI-based plugins."

Full Story (comments: none)

New release of NtEd - 0.23.0

Version 0.23.0 of NtEd, a musical score editor, is out. "New in NtEd 0.23.0: A unique MIDI IMPORT function: - recognizes triplets - distributes the MIDI tracks onto multiple voices per staff"

Full Story (comments: none)

Science

Modular toolkit for Data Processing 2.3 announced

Version 2.3 of the Modular toolkit for Data Processing (MDP) has been announced, it includes new capabilities and bug fixes. "[MDP] is a Python data processing framework. Implemented algorithms include: Principal Component Analysis (PCA), Independent Component Analysis (ICA), Slow Feature Analysis (SFA), Independent Slow Feature Analysis (ISFA), Growing Neural Gas (GNG), Factor Analysis, Fisher Discriminant Analysis (FDA), Gaussian Classifiers, and Restricted Boltzmann Machines."

Full Story (comments: none)

Web Browsers

Firefox 3 Release Candidate available

The first release candidate for Firefox 3 is now available, with many new features and performance improvements. "This milestone is focused on testing the core functionality provided by many new features and changes to the platform scheduled for Firefox 3. Ongoing planning for Firefox 3 can be followed at the Firefox 3 Planning Center, as well as in mozilla.dev.planning and on irc.mozilla.org in #granparadiso." Click below for more details.

Full Story (comments: 15)

Languages and Tools

C

GCC 4.2.4 Released

Version 4.2.4 of GCC, the Gnu Compiler Collection, has been announced. "GCC 4.2.4 is a bug-fix release, containing fixes for regressions in GCC 4.2.3 relative to previous GCC releases."

Full Story (comments: none)

GCC 4.3.1 Status Report

The May 19, 2008 edition of the GCC 4.3.1 Status Report has been published. "The GCC 4.3 branch is open for commits under normal release branch rules. GCC 4.3.1 is still not ready for release as the x86 direction flag issue (36079) needs to be resolved. We have reached consensus to add a new flag -mcld to allow to work around the kernel bug and to add a configure option to enable/disable this by default. The patch from Uros is implementing the -mcld parts but lacks the configure option part for which no patch exists yet."

Full Story (comments: none)

Caml

Caml Weekly News

The May 20, 2008 edition of the Caml Weekly News is out with new articles about the Caml language.

Full Story (comments: none)

Java

OpenSwing: 1.6 released (SourceForge)

Version 1.6 of OpenSwing has been announced, it includes many new capabilities and some bug fixes. "OpenSwing is a component library that provides a rich set of advanced graphics components and a framework for developing java applications based on Swing front-end. It can be applied both to rich client applications and Rich Internet Applications."

Comments (none posted)

Lisp

CMUCL 19e released

Version 19e of CMU Common Lisp has been announced. "This version fixes several ANSI compliance issue, and includes several more enhancements and bug fixes."

Full Story (comments: none)

GNU CLISP 2.45 released

Version 2.45of GNU CLISP has been announced. "This version adds just-in-time compilation of closures, pre-opening of shared libraries, foreign pointer introspection, access to versioned library symbols, new Gray stream functions, and fixes many bugs. CLISP is one of the most popular and actively maintained open-source Common Lisp implementations."

Full Story (comments: none)

Perl

Parrot 0.6.2 released

Version 0.6.2 of Parrot has been announced. "On behalf of the Parrot team, I'm proud to announce Parrot 0.6.2 "Reverse Sublimation." Parrot is a virtual machine aimed at running all dynamic languages."

Full Story (comments: none)

This Week on perl5-porters (use Perl)

The May 4-10, 2008 edition of This Week on perl5-porters is out with the latest Perl 5 news.

Comments (none posted)

Python

Pyrex 0.9.8.2 announced

Version 0.9.8.2 of Pyrex, a language for writing Python extension modules, is available. "A block of external functions can now be declared nogil at once. cdef extern from "somewhere.h" nogil: ... Also some minor nogil-related bugs have been fixed."

Full Story (comments: none)

Python-URL! - weekly Python news and links

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

Full Story (comments: none)

IDEs

eric 4.1.4 released

Version 4.1.4 of eric, an IDE for Python and Ruby, is out. "It includes a fix for an API change of Qt 4.4, that caused eric4 to crash. Please update immediately."

Full Story (comments: none)

Libraries

Urwid 0.9.8.2 released

Version 0.9.8.2 of Urwid, a console UI library for Python, is out. "This is a maintenance release that fixes a number of bugs that have been found in 0.9.8.1."

Full Story (comments: none)

Page editor: Forrest Cook

Linux in the news

Recommended Reading

The pragmatic extremists

Rahul Sundaram takes a look at the Guidelines for Free System Distributions. "I have been spending the last couple of weeks talking to them about clarifying where exactly they are drawing the lines on what constitutes a free system beyond just software and today, FSF just again proved to be quite reasonable by publishing the free system distribution guidelines based on the Fedora licensing guidelines. While I just send my detailed list of feedback on these guidelines and we are not done just yet, I hope this proves to be a useful document to everyone involved and all hail the pragmatic extremists for that. The world is just better off with them in it despite all their own quirks."

Comments (none posted)

Companies

Splashtop Linux desktop to appear on every Asus motherboard (geek.com)

geek.com mentions the inclusion of the fast-booting Splashtop distribution on Asus motherboards. "DeviceVM, the makers of Splashtop, just made a big announcement though. Their technology will no longer be restricted to the top-shelf motherboards and will see a much wider release. At first it will be featured on Asus’ P5Q (high-efficiency design, Intel P45 chipset) family of motherboards, starting with the P5Q Deluxe, P5Q-WS, P5Q3 Deluxe, and P5Q-E. Later Splashtop will be featured on all the company’s motherboards, over a million units a month."

Comments (1 posted)

Verizon joins open Linux mobile group ‘LiMo’ (CrunchGear)

CrunchGear reports that Verizon has joined the LiMo Foundation. "Verizon has signed up as the final member on the board of directors of the LiMo Foundation, a group founded by Motorola, NEC, NTT DoCoMo, Panasonic, Samsung, and Vodafone “to deliver an open and globally consistent software platform based upon Mobile Linux for use by the whole industry to catalyze next-generation mobile consumer experiences.”"

Comments (9 posted)

Linux at Work

A New Goal for Open Source (Red Hat News)

Red Hat News takes a look at a team of soccer playing robots powered by Fedora. "The AllemaniACs use Fedora on every machine they have including desktops, laptops and the systems on the robots. More importantly, much of the software they need to program and communicate with their machines is pre-packaged in Fedora. The AllemaniACs are not only using Fedora, the team has also used its need for specific capabilities to contribute to open source through Fedora. When the team has found a need for open source software not found in Fedora already, they work on packaging it, and then feed that work back into the Fedora community."

Comments (1 posted)

New York Stock Exchange Runs Trades On Red Hat Linux (InformationWeek)

InformationWeek examines the use of Red Hat Linux by the New York Stock Exchange. "Linux has been known to be in use at several New York financial services firms, but few have stepped up to the podium to testify on the value of their implementations. As a result of mergers and acquisitions, the New York Stock Exchange has migrated over the last few years from HP-UX to IBM AIX to Sun Solaris to Linux. NYSE Group CIO Steve Rubinow said the conversion to Linux followed the acquisition of the Euronext exchange in 2007. Unlike some trading companies that suggest Linux is running their secondary systems, Rubinow emphasized that Linux is running the NYSE's mission-critical trading systems."

Comments (12 posted)

Resources

Seeing Linux clearly: Demystifying KDE and GNOME (iTWire)

David M. Williams at iTWire looks at desktop environments, covering what they are and some of the differences between GNOME and KDE. Desktop environments are sometimes a bit of a puzzle for new Linux users; this article should help explain them. "This perhaps may explain why when we talk about KDE and GNOME it’s not immediately apparent just what’s going on. Anyone who comes from a Microsoft Windows or MacOS world has been brought up with the concept that your operating system has just one look. You might be able to tweak it or apply a few colour schemes and minor themes, but fundamentally Windows looks like Windows anywhere. In the Linux world any number of different looks can apply because the window managers are replaceable."

Comments (6 posted)

Page editor: Forrest Cook

Announcements

Non-Commercial announcements

The Digital Standards Organization - The Hague Declaration

David A. Wheeler has sent in a pointer to The Digital Standards Organization (Digistan); "The Digital Standards Organization was founded by open standards professionals in 2007 with the goal of promoting customer choice, vendor competition, and overall growth in the global digital economy through the understanding, development, and adoption of free and open digital standards."

Digistan will be presenting The Hague Declaration on May 21, 2008, to encourage governments to take open standards seriously. Take a look at the declaration and add your signature if you agree.

Comments (18 posted)

Fedora working with Seneca College

Red Hat has announced a partnership with Seneca College wherein students will work with the Fedora project. "A new grant funds a liaison position within the School of Computer Studies to work with Fedora Project members to identify opportunities for student involvement and to guide students as they integrate into the community. This proven model was developed at Seneca and will be incorporated into several programs beginning with the Linux/Unix System Administration (LUX) program, an intense one-year graduate certificate. Fedora projects will be integrated into academic coursework, used as major projects, or funded through government grants."

Full Story (comments: none)

OLPC and Microsoft

The One Laptop Per Child has finally sent out an official communication on its agreement with Microsoft, which involves the creation of a dual-boot version of the XO laptop. "OLPC is substantially increasing its engineering resources and all software development continues entirely on GNU/Linux. We will continue to work to make Sugar on Linux the best possible platform for education and to invest in our expanding Linux deployments in Peru, Uruguay, Mexico and elsewhere. No OLPC resources are going to porting Sugar to Microsoft Windows..."

Full Story (comments: 41)

Announcing Sugar Labs

The Sugar Labs Foundation has announced its existence. "Sugar is the core of the XO laptop's human-computer interface; it provides a fun, easy-to-use, social experience that promotes sharing and learning. Sugar Labs will focus on providing a software ecosystem that enhances learning on the XO laptop as well as other laptops distributed by other companies, such as the ASUS Eee PC. Consistent with the OLPC mission to provide opportunities for learning, an independent Sugar Labs Foundation can deliver learning software to other hardware vendors and, consequently, reach more children."

Comments (none posted)

Commercial announcements

Adobe releases Flash Player 10 beta

Adobe Labs has announced a beta release of Flash Player 10. "Adobe Flash Player 10, code-named "Astro," introduces new expressive features and visual performance improvements that allow interactive designers and developers to build the richest and most immersive Web experiences. These new capabilities also empower the community to extend Flash Player and to take creativity and interactivity to a new level. This public prerelease is an opportunity for developers and consumers to test and provide early feedback to Adobe on new features, enhancements, and compatibility with previously authored content." See the release notes for more information.

Comments (43 posted)

ActivePerl 5.10.0.1003 released by ActiveState

ActiveState has announced the release of ActivePerl 5.10.0.1003 with new DBD::Oracle functionality. "Complete and ready-to-install, ActivePerl includes core Perl, popular modules, the Perl Package Manager (PPM), and complete documentation. With over 250,000 downloads each month, ActivePerl remains the industry-standard for Perl development. ActivePerl is provided free to the community and is available as a supported and OEM product to enterprises globally."

Full Story (comments: none)

Zenoss releases Point-and-Click installers for major Linux Platforms

New installers are available for Zenoss Core. "Zenoss, Inc., a leading provider of commercial open source network, systems and applications management software, today announced availability of the Zenoss Core "Stack," point-and-click installers for leading Linux platforms including Ubuntu Linux, Red Hat's Enterprise Linux and Fedora Core, CentOS, Debian, OpenSUSE and Novell's SUSE Enterprise."

Full Story (comments: none)

New Books

Advanced Rails Recipes--New from Pragmatic Bookshelf

Pragmatic Bookshelf has published the book Advanced Rails Recipes by Mike Clark.

Full Story (comments: none)

Java Power Tools - New From O'Reilly

O'Reilly has published the book Java Power Tools by John Ferguson Smart.

Full Story (comments: none)

JavaScript: The Good Parts--New from O'Reilly

O'Reilly has published the book JavaScript: The Good Parts by Douglas Crockford.

Full Story (comments: none)

Resources

Open Source Security Report

Coverity, Inc. has announced the availability of the Scan Report on Open Source Software 2008. "The Coverity Scan site was developed with support from the U.S. Department of Homeland Security as part of the federal government's 'Open Source Hardening Project.' The report is based on 2 years of analysis of more than 55 million lines of code on a recurring basis from over 250 popular open source projects with Coverity Prevent, the industry-leading static source code analysis solution."

Full Story (comments: 30)

Contests and Awards

White Camel nominations are now open (use Perl)

use Perl has announced that nominations for the White Camel award are open. "Every year, at OSCON, the White Camels are presented. If you look at the previous winners, you'll notice that these are mostly unsung heroes, like previous awardee Eric Cholet, the human moderator of so many Perl mailing lists, or Jay Hannah, one of the people running pm.org (if you ever created/maintained a pm group, chances are that Jay walked you through the process). Some of these people may be well known, like Allison Randal or Randal Schwartz, while others may be complete strangers to at least part of the globe, like Josh McAdams or Jay."

Comments (none posted)

Education and Certification

Python and Plone Boot Camps in Chapel Hill, NC

Several Python and Plone boot camps will take place in North Carolina during August, 2008. "Triangle (NC) Zope and Python Users Group (TriZPUG) is proud to open registration for our fourth annual ultra-low cost Plone and Python training camps, BootCampArama 2008".

Full Story (comments: none)

Calls for Presentations

Hack.lu 2008 cfp

A call for papers has gone out for Hack.lu 2008. The event will take place in Luxembourg on October 22-24, 2008, submissions are due by July 1. "The purpose of the hack.lu convention is to give an open and free playground where people can discuss the implication of new technologies in society. hack.lu is a balanced mix convention where technical and non-technical people can meet each others and share freely all kind of information."

Full Story (comments: none)

Upcoming Events

Netfilter Workshop 2008 announced

The Netfilter Workshop 2008 has been announced. "Following the lastest successful workshop in Karlsruhe, Germany, in October 2007. We are happy to announce the next edition in the workshop series. This year the event will be hosted in Paris, France from September 29th to October 3rd, 2008."

Full Story (comments: none)

Open Source City - Liverpool

Open Source City will take place in Liverpool, UK on June 17-22, 2008. "Open Source City tips its hat to Liverpool’s pioneering spirit by offering a programme of workshops, masterclasses, talks and concerts that shed light on the growing impact of Free/Libre Open Source Software on the creative practices of today, in particular in media art and music."

Comments (none posted)

Events: May 29, 2008 to July 28, 2008

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

Date(s)EventLocation
May 28
May 31
LinuxTag 2008 where .com meets .org Berlin, Germany
May 29
June 1
RailsConf 2008 Portland, OR, USA
May 29
May 30
SyScan’08 Hong Kong Hong Kong, China
May 30
May 31
eLiberatica 2008 - The benefits of Open and Free Technologies Bucharest, Romania
June 2
June 5
VON.x Europe Amsterdam, the Netherlands
June 3
June 4
Nordic Nagios Meet Stockholm, Sweden
June 6
June 7
Portuguese Perl Workshop Braga, Portugal
June 6
June 7
European Tcl/Tk User Meeting 2008 Strasbourg, France
June 9
June 13
Python Bootcamp with David Beazley Atlanta, Georgia, USA
June 10
June 15
REcon 2008 Montreal, Quebec, Canada
June 11
June 13
kvm developer's forum 2008 Napa, CA, USA
June 16
June 18
YAPC::NA 2008 Chicago, IL, USA
June 17
June 22
Liverpool Open Source City Liverpool, England
June 18
June 20
Red Hat Summit 2008 Boston, MA, USA
June 18
June 20
National Computer and Information Security Conference ACIS 2008 Bogota, Columbia
June 19
June 21
Fedora Users and Developers Conference Boston, MA, USA
June 22
June 27
2008 USENIX Annual Technical Conference Boston, MA, USA
June 23
June 24
O'Reilly Velocity Conference San Francisco, CA, USA
June 28
June 29
Rockbox Euro Devcon 2008 Berlin, Germany
July 1
July 5
Libre Software Meeting 2008 Mont-de-Marsan, France
July 3
July 4
SyScan’08 Singapore Novotel Clarke Quay, Singapore
July 3 Penguin in a Box 2008: Embedded Linux Seminar Herzelia, Israel
July 5 Open Tech 2008 London, England
July 7
July 12
EuroPython 2008 Vilnius, Lithuania
July 7
July 12
GUADEC 2008 Istanbul, Turkey
July 14
July 18
PHP 5 & PostgreSQL Bootcamp at the Big Nerd Ranch Atlanta, USA
July 18
July 20
RubyFringe Canada, Toronto
July 19 Firebird Developers Day Piracicaba-SP, Brazil
July 19
July 25
Ruby & Ruby on Rails Bootcamp at the Big Nerd Ranch Atlanta, USA
July 19
July 20
LugRadio Live 2008 - UK Wolverhampton, United Kingdom
July 20 OSCON PDXPUG Day Portland, OR, USA
July 21
July 25
O'Reilly Open Source Convention Portland, OR, USA
July 21
July 22
Ubuntu Live - cancelled Portland, Oregon, USA
July 23
July 26
Ottawa Linux Symposium Ottawa, Canada
July 26 PyOhio 2008 Columbus, OH, USA
July 26
July 27
EuroSciPy2008 Leipzig, Germany

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

Audio and Video programs

Videos from the Linux Foundation Collaboration Summit

The Linux Foundation has posted a series of videos from the Collaboration Summit held in Austin. There's a bunch of interesting stuff there, but, unfortunately, the videos are in Flash format and, thus, will not collaborate well with a lot of Linux systems. The word from the Foundation is that the company hired to do the video work wasn't able to figure out how to produce the final result in an open format.

Comments (3 posted)

Page editor: Forrest Cook

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