LWN.net Weekly Edition for August 28, 2008 [LWN.net]

Django nears 1.0 milestone

By Jake Edge
August 27, 2008

The Django web application framework is nearing an important milestone: version 1.0. Like Ruby on Rails, TurboGears, and others, Django is meant to streamline application development for the web by providing easy-to-use libraries for tasks that are commonly performed by dynamic web sites, such as database access and HTML templating. The Django project has just released the second beta of the 1.0 release, with the final release due in early September.

Django is Python-based, with an eye towards getting an application—or the beginnings of one—up and running quickly. The framework is quite "Pythonic", so it will be very accessible to those used to programming in that language. Django also has an extensive set of documentation including an on-line (and dead tree) book.

While Django can be used to build nearly any kind of web site, it has a "sweet spot" that is well described in the introduction to The Django Book:

Because Django was born in a news environment, it offers several features (particularly its admin interface, covered in Chapter 6) that are particularly well suited for "content" sites – sites like eBay, craigslist.org, and washingtonpost.com that offer dynamic, database-driven information. (Don't let that turn you off, though – although Django is particularly good for developing those sorts of sites, that doesn't preclude it from being an effective tool for building any sort of dynamic Web site. There's a difference between being particularly effective at something and being ineffective at other things.)

The database abstraction (or model) layer is at the heart of what Django provides to a programmer. Most dynamic web sites use some kind of database, so Django supports multiple, popular database systems, of both free software and commercial varieties. Because the model layer is a high-level description of the data, moving from one database backend to another is greatly simplified. In addition, the flexibility of the model API means that many applications can do all of the queries that they need without ever descending into SQL—though the facility is there if it is needed.

An example taken from the book nicely illustrates the simplicity of Django's model API:

    class Book(models.Model):
	name = models.CharField(maxlength=50)
	pub_date = models.DateField()

From this information, along with some configuration concerning database type and name, Django can generate and execute the appropriate SQL to build a database table to store a Book. As fields get added and removed from the model, the proper commands to synchronize the model and the database can be generated. From application code (i.e. the "view" code), then, models can be used in various ways, for instance:

    def latest_books(request):
	book_list = Book.objects.order_by('-pub_date')[:10]
	return render_to_response('latest_books.html', {'book_list': book_list})

This can then be used in an HTML template as follows:

    <h1>Books</h1>
    <ul>
    {% for book in book_list %}
    <li>{{ book.name }}</li>
    {% endfor %}
    </ul>

That is, of course, a simple example, (and it lacks the URL mapping piece) but it gives a flavor of the power that Django provides. It is also an example that most folks, even non-programmers, can follow to some extent. Like many model-view-controller (MVC) based frameworks, Django splits up the various pieces of functionality in an attempt to break the coupling between the user interface, "business" logic, and data storage, allowing each to be worked on separately. In particular, the template language is meant to be used by web page designers who have little programming background.

One of the nicer features is the automatically generated administrative interface. Many web frameworks have incorporated an easy way for a site administrator to start entering data into their models. This allows developers to get their application running quickly with real data without having to code up a bunch of tedious data entry forms. One of the bigger changes from the current 0.96 Django release and the upcoming 1.0 is a complete overhaul of this interface.

Many developers have been using the development versions of Django from the subversion repository because the released version (which is what is packaged by distributions) has lagged. There are a number of backward-incompatible changes since 0.96 and the documentation is geared towards the 1.0 version (though it should be noted that versions for each of the last two releases are also readily available). Stabilizing the API has been the driving force behind the 1.0 release. Going forward, compatibility will be maintained unless a security or other serious problem is found.

Django has numerous other interesting features: authentication, session handling, and a caching system that is geared towards scalability. It is also fully ready for internationalization, with "full support for multi-language applications, letting you specify translation strings and providing hooks for language-specific functionality."

Due to be released on September 2, just in time for DjangoCon, 1.0 is, unsurprisingly, both feature and "string" frozen—only serious bug fixes are still going in. Like other projects, including Python itself, Django is "governed" by an independent foundation; the newly formed Django Software Foundation in this case. The original developers of Django are still active both as foundation board members and as active developers (and users) of Django.

There are lots of web frameworks to choose from, in nearly every computer language used today—though none for COBOL as far as we have heard—so Django is just "yet another" web framework at some level. Django does have some things going for it that others may lack: a development community that is active and uses the framework (generally the development version checked out of the subversion repository) for live, high-volume sites, excellent documentation, and a well thought-out design. For anyone looking for a Python-based web application framework, at least taking Django for a spin will be time well spent.

Comments (10 posted)

Fedora, Red Hat, and distributor security

By Jonathan Corbet
August 25, 2008

On August 22, the Fedora Project released an "infrastructure report" confirming what most observers had, by then, suspected: the project had suffered a major security breach. The attacker got as far as a system used to sign packages distributed by Fedora. That, of course, is something close to a worst-case scenario: if an intruder has control over such a system, it's a relatively small step to capture the package signing key and the passphrase used to employ that key. And those, in turn, could be used to create hostile packages which would be accepted as genuine by Fedora installations worldwide.

Fortunately for the Fedora Project (and its users), an audit has determined that nobody made use of the key while the intruder was present. So, even if some means for capturing something as transient as the passphrase were in place, that passphrase was not exposed, and, thus, cannot have been compromised.

Needless to say, the project is changing its package signing key anyway.

Interestingly, the Fedora Project was not the only target in this attack: Red Hat, too, was compromised. Unlike Fedora, Red Hat did not issue a statement specifically about this intrusion; instead, the information was included in an openssh security update. In this case, the attacker was more successful, to the point of being able to sign "...a small number of OpenSSH packages relating only to Red Hat Enterprise Linux 4 (i386 and x86_64 architectures only) and Red Hat Enterprise Linux 5 (x86_64 architecture only)." This language deserves to be questioned: it is only necessary to sign a single openssh package (certainly qualifying as a "small number") to compromise thousands of RHEL hosts, and the "only" terms describe what must be a large majority of deployed RHEL systems. Seriously scary, but Red Hat has been able to convince itself that none of the compromised packages were fed out to RHEL subscribers. So this attack, too, failed - but not by much.

Needless to say, disclosures like this raise more questions than they answer. The one question that Fedora and Red Hat will have to answer at some point is this: how did the intruder get in? One assumes that Fedora and Red Hat are running their own distributions on their internal systems; it thus stands to reason that, if those distributions contained a vulnerability that allowed the attacker to get in, many other systems will also be vulnerable. If, instead, this compromise is the result of administrator or developer error (or, say, of a lost laptop), administrators responsible for Fedora and RHEL systems can breathe a little easier. Either way, they deserve to know how this series of events came to pass.

Some people would like to have that information immediately. Beyond that, there has, predictably, been a fair amount of grumbling (also predictably, from a relatively small number of people) on the Fedora lists on how this incident was handled. Your editor, too, has argued that some information took too long to emerge. He will now argue that, while Fedora still has more to disclose, the project has said enough to give itself some breathing room while it struggles to put its infrastructure back together and figure out what really happened. There's all kinds of good reasons why more information may not be immediately forthcoming, including the obvious possibility that nobody really knows yet how the intruder gained access. There is little to be gained from hammering on Fedora at this point at this time.

That said, anything the project can say to tell its users whether they should be worried about an undisclosed vulnerability in their systems would be most welcome, and sooner would be better than later.

Meanwhile, what can be done, and what Fedora board member Jeff Spaleta, in particular, has been pushing for, is to think about how things should be handled the next time. Says Jeff:

Did we have a communication problem? Maybe. But communication problems are not equivalent to trust issues. But considering that was a first of its kind event for us as a project, I don't think its necessarily unexpected to see some miscommunication. I don't think any of us, either inside Red Hat or outside had talked through how this sort of thing should be handled. I don't remember a serious public discussion about how to deal with communication of an event like this before having an event like this. And I'm not going to let the assumption stand that to do things differently should have been obvious to those in a position to deal with the information...

If people want things to be better, if god forbid something like this happens again, then a serious effort to write a communication process has to be written up and it must be agreeable to legal as a workable process that won't set off any legal liability landmines.

The Fedora Project should certainly write up a policy for situations like this. It would be good for Fedora's users, but it could have an effect far beyond that: such a policy could serve as an example for other distributors as well. It is, after all, probably safe to say that Fedora is not the only distributor which has, thus far, neglected to put plans in place for this sort of disaster.

We all need such plans. For better or for worse, distributors have come to occupy an important position with regard to the security of much of the net. Millions of systems run packages signed by Linux distributors; they depend, implicitly, on the security of the process used to create those packages. That process is not a small one; it can involve hundreds of developers, before even counting all of those involved in upstream development projects. The consequences of a failure anywhere in that chain of trust can be severe. It is not surprising that the distribution system was attacked; perhaps the only real surprise is that it has not happened more often - that we know of. These attacks will happen again; distributors need to have a firm idea of how they will respond.

A related subject is worth a quick mention: as of this writing, the Fedora Project has issued no security updates since August 12, almost a full two weeks. A number of significant vulnerabilities, including the postfix symbolic link vulnerability, remain unpatched for Fedora users. Red Hat has done better, but not by much. Linux users depend heavily on the distributor security update process, and, for these two distributions, that process has been severely disrupted. If there had been a truly serious vulnerability disclosed during this time, people charged with keeping Fedora and RHEL systems secure might have found themselves in a difficult position. One need not be overly paranoid to envision this type of disruption being done intentionally as part of a zero-day attack on the net.

This incident should serve as a sort of wake-up call for both distributors and their users. Distributors wanting to retain their users' trust should be thinking about documenting things like:

How the packaging chain is kept secure. It would be good to know how many people are able to sign packages, and how they gain access to the systems where this signing is done.
What sort of plans the distributor has in place for dealing with security problems. One can only assume that Red Hat dedicated (and continues to dedicate) a large amount of staff time to understanding and recovering from this incident. Would other distributors be willing and able to do the same?
What are the plans for dealing with a major security breach? How might a critical security update be propagated during a time when the integrity of the packaging system has been compromised?
Should something go wrong, when and how will information be communicated to the wider community?

Conversely, anybody who is deploying an important Linux-based system should be asking such questions when choosing a distribution for that system. If the system requires high-assurance guarantees in this regard, it probably makes sense to look at the vendors who are willing to provide such guarantees for a fee. But, again, the lesson we have learned from recent events is that the time to ask these questions is now, and not when something has gone wrong and people are running around in circles.

As a whole, Linux users have been very well served by distributors since the very beginning. The distributors pull together thousands of software releases and integrate them into a coherent whole; they then make the results available, often for free. They provide fixes when things break, and most of them pay particular attention to fixing security-related problems. And they have done a top-quality job of not being used as a conduit for hostile software. It's a great system, and that has not changed. But we have learned something about how heavily we depend on that system, and how it can fail. Proper application of the lessons from this episode should help us all to be more secure in the future.

Comments (20 posted)

EFF continues fight for rights and freedoms

August 27, 2008

This article was contributed by Lisa Hoover

There's little doubt that emerging technology is improving our way of life, but it's also creating a quagmire of legal issues surrounding the rights and restrictions we face while living in a digital age. The once ambiguous concept of "digital rights" has now become an all-encompassing term used to designate a wide range of rights that have the potential to be trampled on as courts sort out how Constitutional freedom applies to emerging and existing technologies.

LWN recently chronicled GeekPAC, an organization looking for new ways to protect our rights via the political battlefront. The Electronic Frontier Foundation (EFF), one of the oldest non-profit organizations dedicated to establishing and defending our rights in a digital world, takes a different approach.

Since the EFF's mission encompasses such a large body of issues, it's no longer practical to say they're protecting "digital rights." Rebecca Jeschke, Media Relations Coordinator for the EFF, says, "Instead, in our increasingly networked world, they are simply 'rights.' But we'll continue to educate folks on the issues." To do so, the EFF focuses its energies on several important issues including free speech, intellectual property, privacy, and innovation. At first blush, it may be easy to dismiss the work they do as something that only applies to people who download music illegally or who need to protect their online content from thieves. In fact, it may surprise some people to know that the EFF also defends the privacy of airline travelers and cell phone users, issues not typically associated with the purveyors of digital freedoms.

One of the reasons the EFF's reach is so wide is because of the way technology infiltrates our everyday lives. It's easy to understand why sharing the contents of a store-bought music CD with hundreds of people on the Internet may infringe on the rights of the artist hoping to sell his music. In the case of an airline traveler, rights infringement takes on a completely new form when the Transportation Safety Administration's data analysis and screening software wrongly decides someone is a security risk. Not only is there no way to challenge the error, it's a mistake that's likely to haunt them for the rest of their lives.

The more pervasive technology becomes, the more stories of this nature arise. Take, for example, the seemingly innocuous library book. Many public and school libraries are employing RFID technology to track books and other borrowed items. People throw these books into their bag or backpack without realizing the affixed tracking tags can actually be used to track them as well. It's doubtful the government would be interested in the whereabouts of a 9-year old walking home from school, but it's easy to see how this technology can be mishandled or abused.

To be sure, no one is suggesting that technology be removed from our daily lives. The mission of the EFF and its supporters is to effect accountability and protect people's rights within the courts.

Jeschke says one of the biggest battles surrounding digital freedom that we're likely to hear about in the next year or so is the issue of coders' rights. In response to a gradual uptick of cases in which coders, software engineers, and computer science students are being falsely accused of hacking and other nefarious crimes, the EFF has developed the Coders' Rights Project.

According to the EFF, coders are becoming reluctant to explore and research ways to make our technology safer for fear of being prosecuted under laws like the Digital Millennium Copyright Act (DMCA) and the Computer Fraud and Abuse Act. The Coders' Rights Project protects researchers through "education, legal defense, amicus briefs and involvement in the community with the goal of promoting innovation and safeguarding the rights of curious tinkerers and hackers on the digital frontier."

Jeschke says another big issue to watch involves the National Security Agency (NSA) and its interest in wiretapping phones and email without first obtaining a court order. Though expressly illegal since 1978, President George W. Bush authorized the NSA to proceed anyway and when the news became public in 2005, the EFF immediately sprang into action against the telecommunications companies assisting the government with their illegal practice. Congress passed an amendment of the original law that grants telecommunications companies immunity, and the EFF is currently working to have that law repealed.

Other issues of importance in the upcoming months are expected to be in the area of copyright and fair use in user-generated content. The proliferation of YouTube and other online video hosting sites are creating a new and exciting level of creativity, along with some cinema screen-sized headaches about how content owned by others is permitted to be used..

For example, a homegrown animated video of original content is fine to post online. Setting that video to a favorite Rolling Stones song, however, crosses the line into copyright infringement. Or does it? What if the main character is simply wearing a t-shirt bearing the band's hand-drawn logo? These are some of the issues the EFF is hoping to sort out.

As a non-profit organization, the EFF is funded solely through individual and corporate donations. In fact, a full two-thirds of the foundation's operating budget comes from individual donations, much of which is funneled directly into litigation.

The EFF's status as a charitable organization does not permit the solicitation of politicians and governmental figures to support its cause. Instead, the foundation fights legal battles in court, advises policymakers, and uses it's corps of 50,000 volunteers to educate the public.

One such EFF contributor is SourceForge.net Community Manager Ross Turk, who has been donating consistently to the EFF for 3 years and has been a staunch supporter for much longer. He says:

I think the world is changing. Technology has made things possible now that weren't possible before, but I think the system has become highly motivated to preserve itself by making sure people don't do things in new and interesting ways. The EFF's mission is, as I see it, to help the system adapt to the world that we live in today by forcing it to take a closer look at the way it deals with patents, the limitless power it grants industry, and the way it views free speech in an online age.

I like that they protect the world's innovators, and I like that they thwart those who try to use the technology we have created to monitor and control us. I'm also very happy to know that they're there to help us protect members of our community who are attacked for doing what they like to do.

Turk also notes that EFF Bootcamp, a one day training session presented by the foundation's attorneys has benefited him professionally because it helped him "understand the difference between enforcement and oppression."

It's precisely that kind of education that has kept the EFF going strong for 18 years. The first step in protecting our rights in the burgeoning age of technology is to understand how the things we invent and rely on have the potential to impact our freedoms.

Comments (6 posted)

Welcome to the new LWN server

LWN.net has been running on the same server for several years, generously donated to us by the folks at Rackspace.com. This server ran on a mighty 1.3 GHz CPU, and, while it was up to the task most of the time, it was clearly beginning to show its age. Perhaps more amusingly, the server has retained the same RHEL 2 operating system it came with. So, for all these years, LWN readers have been getting their bleeding-edge kernel news from a machine running a kernel which claims to be version 2.4.9.

Those days are now done; LWN has moved on to a shiny, new, dual-core processor at a new hosting provider. For the time being, the extra computing power will be dedicated to making the current site faster; over the longer term, we hope to add some of the more database-intensive features that have been on our "to do" list for years.

As part of the upgrade, there has been a small change to LWN's format; we have added a third column on the right of the main content. The main goal was to move advertisements over there and to get them out of the content itself; that, we hope, will improve the LWN reading experience.

There are a couple of new account configuration options which tie into the format change; it is now possible to set the maximum and minimum width of the central column. The maximum width preference replaces the hard-coded maximum which LWN has used for a while; people who like to read really long lines of text will now be able to do so. Others (like your editor) who don't like to see the real content of the site squeezed too tightly in a narrow window can set the minimum value and prevent that from happening.

Of course, if you set the minimum too high, you risk pushing the right column out of the window entirely and missing important communications from our advertisers; we know you wouldn't want to do that.

Various other changes have been made as well, but most of them are not that significant. Hopefully it all adds up to a better LWN. There's probably a glitch or two left; please drop us a note at lwn@lwn.net should you find one.

Comments (24 posted)

A free ticket for the Linux Plumbers Conference

LWN contributor Valerie Henson not only writes good articles, she has good ideas as well. She has an extra ticket for the upcoming Linux Plumbers Conference that she has offered to give to a deserving soul. As it turns out, LWN also has an extra ticket for the conference by virtue of being a press partner. We would like to give that ticket to some deserving hacker, preferably one that would like to write an article or two about conference sessions they attend.

The conference is in Portland, Oregon in mid-September, and, alas, we cannot offer any transportation or accommodation assistance. But, we would be more than happy to pay for articles from the conference. Check out our Author Guide for more information on that. You would have to coordinate with that Grumpy Editor guy on article topics.

If you are interested, drop a note to lwn@lwn.net. Please give us some idea of why you want to go, whether you might be able to write an article or two, etc. Obviously, you would need to be able to get to Portland, take the time off work, find some place to sleep, and so forth. We will choose someone to go on Friday 29 August, 2008.

Comments (1 posted)

Page editor: Jonathan Corbet

Security

Firefox 3 SSL certificate warnings

By Jake Edge
August 27, 2008

Users of Firefox 3 have likely seen the new warnings for various "invalid" SSL certificates. Unlike earlier versions of Firefox, these new warnings are much scarier, as well as more difficult to ignore—clicking through to the web site is decidedly more time consuming. This is exactly as the Mozilla folks intend, but it has raised some eyebrows, and ire, amongst site owners and Firefox users.

SSL certificates are used to enable encrypted communication (i.e. https) between browsers and web sites. Web site owners generate a public and private key for use in the encryption. The public key gets wrapped up in an X.509 certificate and must be signed by someone. For larger sites, it is typically a certificate authority (CA) that signs the certificate, but that generally costs money. Many smaller sites will sign their own certificate creating what is known as a self-signed certificate

As part of the negotiation of an encrypted connection, a web site will present its certificate to the browser. In order to prevent man-in-the-middle attacks against the encrypted connection, the browser needs to verify that the certificate belongs to the web site it believes it is talking to. It does that by verifying the signature of the CA.

A signature can only be verified if the browser has the public key of the CA that has signed the certificate. Because there are a multitude of CAs, a "web of trust" is established whereby a number of root CAs sign the certificate of lesser CAs, who might in turn sign for other CAs. A browser developer, like Mozilla, chooses a set of root certificates that they trust. When verifying the certificate from some random website, the browser follows the signature chain; if it reaches one of their root certificates, the web site certificate is valid. A self-signed certificate will, of course, fail this test.

When a user comes across a site that has such a certificate, Firefox 3 puts up a nasty warning. The images that accompany this article are screenshots of the warning, along with two of the three steps one must take to accept the certificate. They were generated by visiting https://bugzilla.gnome.org. The days of a single pop-up message that could easily be clicked through are long gone.

There are a few different issues here. To start with, there are a large number of legitimate sites that have self-signed certificates. In order to access those sites, users are being trained to click through a series of dialogs and scary ("Legitimate banks, stores, and other public sites will not ask you to do this") warnings, just as they were trained to do with single pop-up message in earlier Firefox versions.

Mozilla's position is that self-signed certificates are untrustworthy, not invalid necessarily, but not something that the browser can trust without asking the user. Because most users are not very sophisticated, the warnings need to be detailed and somewhat frightening. The problem is that users of all kinds may get annoyed by the dialogs—then train themselves to essentially ignore them.

Because there are CAs, like StartSSL, that provide free certificate signing (as well as others that cost less than $20/year), Mozilla is clearly trying to push web sites into moving away from self signing. There is a risk of man-in-the-middle attacks from self-signed certificates because anyone can create certificate that purports to be for any other given web site. To some extent, though, the level of danger depends on what the encryption is trying to protect.

For sites that do e-commerce or transmit and receive sensitive information, there is no question that a CA signed certificate is required. There are other reasons to encrypt traffic, though, including evading deep packet inspection (DPI), where the risks of accepting a bogus certificate are relatively low. One might get ads injected into their web browser inappropriately—annoying, but hardly fatal.

There is no simple solution. Mozilla is erring on the side of caution by trying to protect its users while still allowing them to override its protections. Other techniques, possibly like the Perspectives Firefox extension, may help alleviate the problem in the long term. Until then, we may have to just grit our teeth and click our way past the multiple warnings.

Comments (29 posted)

Brief items

CERT warns about SSH key-based attacks

CERT has sent out an advisory on key-based attacks being used against Linux systems. "The attack appears to initially use stolen SSH keys to gain access to a system, and then uses local kernel exploits to gain root access. Once root access has been obtained, a rootkit known as 'phalanx2' is installed." There's no talk of where the original stolen keys come from. CERT's advice includes disabling key-based authentication, which, of course, runs counter to the advice given to those trying to defend against brute-force password-guessing attacks.

Comments (23 posted)

Perspectives: an extension to block man-in-the-middle attacks

A group at Carnegie Mellon University has announced the availability of a Firefox extension called "Perspectives"; its purpose is to provide an independent verification of SSL HTTP connections. "Perspectives employs a set of friendly sites, or 'notaries,' that can aid in authenticating Web sites for financial services, online retailers and other transactions requiring secure communications. By independently querying the desired target site, the notaries can check whether each is receiving the same authentication information, called a digital certificate, in response." The system also gets rid of the obnoxious Firefox popups associated with self-signed certificates; more information on the Perspectives page.

Full Story (comments: 24)

Revealed: The Internet's Biggest Security Hole (Wired)

Wired covers a talk given at DefCon about vulnerabilities in the Border Gateway Protocol (BGP) which is the protocol used to advertise routes for internet traffic. The attack can hijack packets bound for a particular IP address, then silently send them on to the proper destination—possibly after modifying them. "The issue exists because BGP's architecture is based on trust. To make it easy, say, for e-mail from Sprint customers in California to reach Telefonica customers in Spain, networks for these companies and others communicate through BGP routers to indicate when they're the quickest, most efficient route for the data to reach its destination. But BGP assumes that when a router says it's the best path, it's telling the truth. That gullibility makes it easy for eavesdroppers to fool routers into sending them traffic."

Comments (17 posted)

New vulnerabilities

ipsec-tools: two denial of service vulnerabilities

Package(s):

ipsec-tools

CVE #(s):

CVE-2008-3651 CVE-2008-3652

Created:

August 27, 2008

Updated:

May 19, 2009

Description:

From the Red Hat advisory:

Two denial of service flaws were found in the ipsec-tools racoon daemon. It was possible for a remote attacker to cause the racoon daemon to consume all available memory. (CVE-2008-3651, CVE-2008-3652)

Alerts:

SuSE	SUSE-SR:2009:004	2009-02-17
Gentoo	200812-03	2008-12-02
SuSE	SUSE-SR:2008:025	2008-11-14
Fedora	FEDORA-2008-9016	2008-11-07
Fedora	FEDORA-2008-9007	2008-11-07
Ubuntu	USN-641-1	2008-09-09
Mandriva	MDVSA-2008:181	2007-08-28
CentOS	CESA-2008:0849	2008-08-27
Red Hat	RHSA-2008:0849-01	2008-08-26

Comments (none posted)

java: vulnerable versions can be requested by applet

Package(s):

java

CVE #(s):

CVE-2008-3115

Created:

August 25, 2008

Updated:

November 18, 2009

Description:

From the SUSE advisory:

CVE-2008-3115: Secure Static Versioning in Sun Java JDK and JRE 6 Update 6 and earlier, and 5.0 Update 6 through 15, does not properly prevent execution of applets on older JRE releases, which might allow remote attackers to exploit vulnerabilities in these older releases.

Alerts:

Gentoo	200911-02	2009-11-17
SuSE	SUSE-SA:2008:042	2008-08-25

Comments (none posted)

kernel: several vulnerabilities

Package(s):

kernel

CVE #(s):

CVE-2008-2931 CVE-2008-3272 CVE-2008-3275

Created:

August 26, 2008

Updated:

September 1, 2010

Description:

From the Ubuntu advisory:

The do_change_type routine did not correctly validation administrative users. A local attacker could exploit this to block mount points or cause private mounts to be shared, leading to denial of service or a possible loss of privacy. (CVE-2008-2931)

Tobias Klein discovered that the OSS interface through ALSA did not correctly validate the device number. A local attacker could exploit this to access sensitive kernel memory, leading to a denial of service or a loss of privacy. (CVE-2008-3272)

Zoltan Sogor discovered that new directory entries could be added to already deleted directories. A local attacker could exploit this, filling up available memory and disk space, leading to a denial of service. (CVE-2008-3275)

Alerts:

SUSE	SUSE-SA:2010:036	2010-09-01
Red Hat	RHSA-2008:0787-01	2009-01-05
CentOS	CESA-2009:0014	2009-01-15
CentOS	CESA-2008:0973	2008-12-17
Red Hat	RHSA-2008:0973-03	2008-12-16
Mandriva	MDVSA-2008:220-1	2008-11-19
CentOS	CESA-2008:0972	2008-11-20
Red Hat	RHSA-2008:0972-01	2008-11-19
SuSE	SUSE-SR:2008:025	2008-11-14
Red Hat	RHSA-2009:0001-01	2009-01-08
Mandriva	MDVSA-2008:220	2008-10-29
SuSE	SUSE-SA:2008:052	2008-10-21
Red Hat	RHSA-2008:0857-02	2008-10-07
SuSE	SUSE-SA:2008:049	2008-10-02
SuSE	SUSE-SA:2008:048	2008-10-01
SuSE	SUSE-SA:2008:047	2008-10-01
Red Hat	RHSA-2009:0014-01	2009-01-14
CentOS	CESA-2008:0885	2008-09-25
Red Hat	RHSA-2008:0885-01	2008-09-24
Debian	DSA-1636-1	2008-09-11
SuSE	SUSE-SA:2008:044	2008-09-11
Ubuntu	USN-637-1	2008-08-25

Comments (none posted)

libxml2: denial of service

Package(s):

libxml2

CVE #(s):

CVE-2008-3281

Created:

August 22, 2008

Updated:

December 2, 2008

Description:

From the Mandriva advisory: Andreas Solberg found a denial of service flaw in how libxml2 processed certain content. If an application linked against libxml2 processed such malformed XML content, it could cause the application to stop responding

Alerts:

Gentoo	200812-06	2008-12-02
rPath	rPSA-2008-0325-1	2008-11-19
Fedora	FEDORA-2008-8575	2008-10-03
Fedora	FEDORA-2008-8582	2008-10-03
SuSE	SUSE-SR:2008:018	2008-09-19
Ubuntu	USN-644-1	2008-09-11
Mandriva	MDVSA-2008:192	2007-09-11
Fedora	FEDORA-2008-7395	2008-09-05
Fedora	FEDORA-2008-7724	2008-09-05
Ubuntu	USN-640-1	2008-09-03
CentOS	CESA-2008:0836	2008-08-27
Mandriva	MDVSA-2008:180-1	2007-08-26
Debian	DSA-1631-2	2008-08-26
CentOS	CESA-2008:0836-02	2008-08-23
Debian	DSA-1631-1	2008-08-22
Red Hat	RHSA-2008:0836-02	2008-08-21
Mandriva	MDVSA-2008:180	2007-08-21

Comments (none posted)

openoffice.org: numeric truncation error

Package(s):

openoffice.org

CVE #(s):

CVE-2008-3282

Created:

August 27, 2008

Updated:

October 31, 2008

Description:

From the Red Hat advisory:

A numeric truncation error was found in the OpenOffice.org memory allocator. If a carefully crafted file was opened by a victim, an attacker could use this flaw to crash OpenOffice.org or, possibly, execute arbitrary code. (CVE-2008-3282)

Alerts:

Fedora	FEDORA-2008-7680	2008-09-05
Fedora	FEDORA-2008-7531	2008-09-05
CentOS	CESA-2008:0835	2008-08-30
Red Hat	RHSA-2008:0835-01	2008-08-27

Comments (none posted)

tiff: arbitrary code execution

Package(s):

tiff

CVE #(s):

CVE-2008-2327

Created:

August 26, 2008

Updated:

December 4, 2009

Description:

From the Debian alert: Drew Yao discovered that libTIFF, a library for handling the Tagged Image File Format, is vulnerable to a programming error allowing malformed tiff files to lead to a crash or execution of arbitrary code.

Alerts:

Mandriva	MDVSA-2009:169-1	2009-12-03
Mandriva	MDVSA-2009:169	2009-07-28
Mandriva	MDVSA-2009:150	2009-07-13
CentOS	CESA-2008:0847	2008-10-03
SuSE	SUSE-SR:2008:018	2008-09-19
Fedora	FEDORA-2008-7370	2008-09-05
Fedora	FEDORA-2008-7388	2008-09-05
Gentoo	200809-07	2008-09-08
rPath	rPSA-2008-0268-1	2008-09-04
Mandriva	MDVSA-2008:184	2007-09-03
Ubuntu	USN-639-1	2008-09-02
CentOS	CESA-2008:0848	2008-08-30
CentOS	CESA-2008:0863	2008-08-29
Red Hat	RHSA-2008:0863-01	2008-08-28
Red Hat	RHSA-2008:0848-01	2008-08-28
Red Hat	RHSA-2008:0847-01	2008-08-28
Debian	DSA-1632-1	2008-08-26

Comments (none posted)

tomcat: multiple vulnerabilities

Package(s):

tomcat

CVE #(s):

CVE-2008-1232 CVE-2008-2370 CVE-2008-2938

Created:

August 27, 2008

Updated:

February 17, 2009

Description:

From the Red Hat advisory:

A cross-site scripting vulnerability was discovered in the HttpServletResponse.sendError() method. A remote attacker could inject arbitrary web script or HTML via forged HTTP headers. (CVE-2008-1232)

A traversal vulnerability was discovered when using a RequestDispatcher in combination with a servlet or JSP. A remote attacker could utilize a specially-crafted request parameter to access protected web resources. (CVE-2008-2370)

An additional traversal vulnerability was discovered when the "allowLinking" and "URIencoding" settings were activated. A remote attacker could use a UTF-8-encoded request to extend their privileges and obtain local files accessible to the Tomcat process. (CVE-2008-2938)

Alerts:

SuSE	SUSE-SR:2009:004	2009-02-17
Red Hat	RHSA-2008:0864-02	2008-10-02
Red Hat	RHSA-2008:0862-02	2008-10-02
SuSE	SUSE-SR:2008:018	2008-09-19
Fedora	FEDORA-2008-8113	2008-09-16
Fedora	FEDORA-2008-8130	2008-09-16
Fedora	FEDORA-2008-7977	2008-09-11
Mandriva	MDVSA-2008:188	2008-09-05
CentOS	CESA-2008:0648	2008-08-28
Red Hat	RHSA-2008:0648-01	2008-08-27

Comments (none posted)

yelp: format string vulnerability

Package(s):

yelp

CVE #(s):

CVE-2008-3533

Created:

August 21, 2008

Updated:

November 7, 2008

Description:

From the Mandriva alert: A format string vulnerability was discovered in yelp after version 2.19.90 and before 2.24 that could allow remote attackers to execute arbitrary code via format string specifiers in an invalid URI on the command-line or via URI helpers in Firefox, Evolution, or possibly other programs,

Alerts:

SuSE	SUSE-SR:2008:024	2008-11-07
Fedora	FEDORA-2008-7293	2008-09-05
Gentoo	200809-01	2008-09-04
Ubuntu	USN-638-1	2008-08-27
Mandriva	MDVSA-2008:175	2008-08-20

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The current 2.6 development kernel is 2.6.27-rc4, released on August 20. Along with lots of fixes, it includes support for the multitouch trackpad on new Apple laptops, more reshuffling of architecture-specific include files, a number of XFS improvements, interrupt stacks for the SPARC64 architecture, the removal of the obsolete Auerswald USB sound driver, and new drivers for TI TUSB 6010 USB controllers, Inventra HDRC USB controllers, and National Semiconductor adcxx8sxxx analog-to-digital converters. The short-form changelog is in the announcement, or see the long-form changelog for all the details.

Patches continue to accumulate in the mainline repository, and 2.6.27-rc5 may be released by the time you read this. Along with the fixes, -rc5 will include Japanese translations of more kernel documents and generic interrupt handling for some UIO devices.

Comments (none posted)

Kernel development news

Quotes of the week

NOTE: When tempted to use multibyte bitfields on fixed-layout data, you need to look in the mirror, ask yourself "what will they do to me during code review for that?", shudder and decide that some temptations are just not worth the pain.

-- Al Viro

The longer you queue stuff up, the more painful having to change stuff at the beginning of that queue becomes. It can invalidate everything else you worked on.

The only sane way to operate is to post your work early and often, or else you'll live in a world of hurt, and it will be nobody's fault but your own.

-- David Miller

linux-next is not a tree that you can track. It's a tree that you can fetch _once_ and then throw away.

So what you can do is to "fetch" linux-next, and test it. But you MUST NEVER EVER use it for anything else. You can't do development on it, you cannot rebase onto it, you can't do _anything_ with it.

-- Linus Torvalds

We get better regression tests from getting stuff upstream. However upstreaming stuff to Linus is not how to find regressions, it helps but its suboptimal in that he will eventually ignore us if the regression rate gets too high.

-- Dave Airlie

Comments (none posted)

AXFS: a compressed, execute-in-place filesystem

By Jonathan Corbet
August 26, 2008

Filesystems are clearly an area of high development interest at the moment; hardly a week goes by without a new filesystem release for Linux popping up on some list or other. All of this development is motivated by a number of factors, including the increasing size of storage devices and the increasing capability of solid-state storage. Beyond that, though, there is the simple fact that there is no single filesystem which is optimal for all applications. The recently-announced AXFS filesystem is a clear example of what can be done if one targets a specific use case and optimizes for that case only.

At a first impression, AXFS seems like a simple and limited filesystem. It is, for example, read-only; the AXFS developers have made no provision for changing the filesystem after it is created. Some filesystems have a great deal of code dedicated to the creation of the optimal layout of file blocks on disk; AXFS has none of that. Instead, it has a simple format which divides the media into "regions" and, almost certainly, spreads accesses across the device. There is no journaling, no logging, no snapshots, and no multi-device volume management.

What AXFS does provide is compressed storage using zlib. It is, clearly, aimed at embedded systems using flash-based storage. For such devices, a compressed filesystem can be built using the provided tools, then loaded into a minimal amount of flash on each device. It thus joins a number of other compressed filesystems - cramfs and squashfs, for example - provided for this sort of application. One interesting aspect of compressed, flash-oriented filesystems is their apparent ability to stay out of the mainline kernel. By posting AXFS for review on linux-kernel, developer Jared Hulbert may be trying to avoid a similar fate.

The feature which makes AXFS different from squashfs and cramfs is its support for execute-in-place (XIP) files. Some types of flash can be mapped directly into the processor's address space. When running programs stored on that flash, copying pages of executable code from flash into main memory seems like a bit of a waste: since that code is already addressable by the processor, why not run it from the flash? Executing code directly from flash saves RAM; it also makes things faster by eliminating the need to copy those pages into RAM at page fault time. As a result, systems using XIP tend to boot more quickly, a feature which designers (and users) of embedded systems appreciate.

Linux has had an execute in place mechanism for a few years now, but relatively few filesystems make use of it. AXFS has been designed from the beginning to facilitate XIP operation - that's its reason for existence (and the origin of the "X" in its name).

There is an additional twist, though. One would ordinarily consider compressed storage and XIP to be mutually exclusive - there is little value in mapping compressed executable code into a process's address space. To be able to executed in place, a page of code must be stored uncompressed. What makes AXFS unique is its ability to mix compressed and uncompressed pages in the same executable file. So pages which will be frequently accessed can be stored uncompressed and executed in place. Pages with infrequently-needed code or which contain initialized data can be stored compressed to save space and uncompressed at fault time.

This is a slick feature, but it is not of great use if one does not know which pages of an executable file are heavily enough used to justify storing them without compression. Trying to determine this information and manually pick the representation of each page seems like an error-prone exercise - not to mention one which would tend to create high employee turnover. So another method is needed.

To that end, AXFS provides a built-in profiling mechanism. Each AXFS filesystem is represented by a virtual file under /proc/axfs; writing "on" to that file will cause AXFS to make a note of every page fault within the filesystem. Reading that file then yields spreadsheet-like output showing, for each file, how many times each page was faulted into the page cache. Using this data, it is possible to generate an AXFS filesystem image with an optimal number of compressed pages for the target system.

Filesystems normally need a few rounds of review before they can make it into the mainline; some filesystems need rather more than that. AXFS is sufficiently simple, though, that it may find a quicker path into the kernel. So far, the comments have mostly been positive, with the biggest complaint being, perhaps, that its name is too close to that of the existing XFS filesystem. So a 2.6.28 merge for AXFS, while far from guaranteed, would appear to be not entirely out of the question.

Comments (2 posted)

Sysfs and namespaces

By Jonathan Corbet
August 26, 2008

Support for network namespaces - allowing different groups of processes to have a different view of the system's network interfaces, routes, firewall rules, etc. - is nearing completion in recent kernels. A look at net/Kconfig turns up something interesting, though: network namespaces can only be enabled in kernels which do not support sysfs - the two are mutually exclusive. Since most system configurations need sysfs to work properly, this limitation has made it harder than it would otherwise be to use, or even test, the network namespace feature.

The problem is simple: the network subsystem creates a sysfs directory for each network interface on the system. For example, eth0 is represented by /sys/class/net/eth0; therein one can find out just about anything about how eth0 is configured, query its packet statistics, and more. But, when network namespaces are in use, one group of processes may have a different eth0 than another, so they cannot share a globally-accessible sysfs tree. One solution might be to add the network namespace as an explicit level in the sysfs tree, but that would break user-space tools and fails to properly isolate namespaces from each other. The real solution is to build namespace awareness more deeply into sysfs.

Eric Biederman has been working on a set of sysfs namespace patches for the last year or so; those patches now appear to be getting close to ready for inclusion into the mainline. Network namespaces will be the first user of this feature, but it has been written in a way that makes it possible for any system namespace to provide differing views of parts of the sysfs hierarchy.

The core concept is that of a "tagged" directory in sysfs. Any sysfs directory can be associated with (at most) one type of tag, where that type identifies which type of namespace controls how that directory is viewed. Thus, for example, /sys/class/net would have a tag type identifying the network namespace subsystem as the one which is in control there. The /sys/kernel/uids directory, instead, will be managed by the user namespace subsystem. Once a directory is given a tag type, all subdirectories and attribute files inherit the same type.

Namespace code makes use of tagged sysfs directories by adding an entry to enum sysfs_tag_type, defined in <linux/sysfs.h>, to identify its specific tag type. The namespace must also create an operations structure:

    struct sysfs_tag_type_operations {
	const void *(*mount_tag)(void);
    };

The purpose of the mount_tag() method is to return a specific tag (represented by a void * pointer) for the current process. This tag, normally, will just be a pointer to the structure describing the relevant namespace; for example, network namespaces implement this method as follows:

    static const void *net_sysfs_mount_tag(void)
    {
	return current->nsproxy->net_ns;
    }

The tag operations must be registered with sysfs using:

    int sysfs_register_tag_type(enum sysfs_tag_type type, 
                                struct sysfs_tag_type_operations *ops);

Thereafter, there are two ways of associating tags with a sysfs hierarchy. One of those is to make a tagged directory directly with:

    int sysfs_make_tagged_dir(struct kobject *kobj, 
                              enum sysfs_tag_type type);

The directory associated with kobj will have differing contents depending on the value of the tag of the given type. The actual tag associated with the contents of this directory will be determined (at creation time) by calling a new function added to the kobj_type structure:

    const void *(*sysfs_tag)(struct kobject *kobj);

The sysfs_tag() function is usually a short series of container_of() calls which, eventually, locates the appropriate namespace for the given kobj.

An alternative way to attach tags to a directory tree is to associate it directly with the class structure. To that end, struct class has two new members:

    enum sysfs_tag_type tag_type;
    const void *(*sysfs_tag)(struct device *dev);

When the class is instantiated, it will have tags of the given tag_type; the specific tag for a given class will be found by calling the sysfs_tag() function.

Finally, if a specific tag ceases to be valid (because the associated namespace is destroyed, normally), a call should be made to:

    void sysfs_exit_tag(enum sysfs_tag_type type, const void *tag);

This call will cause all sysfs directories with the given tag to become invisible, and to be deleted when it is safe to do so.

Adding tagged directory support requires some significant changes to the sysfs code. But the interface has been designed to make it very easy for other subsystems to make use of tagged directories; it's a simple matter of providing functions to return the specific tag values which should be used. At this point, the biggest challenge might be making sense of sysfs when its contents may be different for each observer. But that is a challenge associated with namespaces in general.

Comments (9 posted)

TALPA strides forward

By Jake Edge
August 27, 2008

When last we left TALPA, it was still floundering around without a solid threat model, but over the last several weeks that part has changed. Eric Paris proposed a fairly straightforward—though still somewhat controversial—model for the threats that TALPA is supposed to handle. With that in place, there is at least a framework for kernel hackers to evaluate different ways to solve the problem, while also keeping in mind other potential uses.

It seems almost tautological, but anti-virus scanning is supposed to, well, scan files. In particular, they scan for known malware and block access to files when they are found to be infected. For better or worse, scanning files is seen as an essential security mechanism by many, so TALPA is trying to provide a means to that end. Paris describes it this way:

This is a file scanner. There may be all sorts of marketing material or general beliefs that they provide security against all sorts of wide and varied threats (and they do), but in all reality the only threats they provide any help against are those that can be found by scanning files. Simple as that. Some may argue this isn't "good" security and I'm not going to make a strong argument to the contrary, I can stand here for days and show cases where this is highly useful but no one can provide a threat model more than to say, "we attempt to locate files which may be harmful somewhere in the digital ecosystem and try to deny access to that data."

All of the various scenarios where active processes can infect files with malware or actively try to avoid scanning can be ignored under this model. While this looks like "security theater" to some, it avoids the endless what-ifs that were bogging down earlier discussions. It may not be a threat model that appeals to many of the kernel hackers, but it is one that they can work with.

To many kernel developers—used to efficiency at nearly any cost—time consuming filesystem scans seem ludicrous, especially since they only "solve" a subset of the malware problem. But the fact remains that Linux users, particularly in "enterprise" environments, believe they need this kind of scanning and are willing to pay for products that provide it. The current methods used by anti-virus vendors to do the scanning are problematic at best, causing users to run kernels tainted with binary modules. With a threat model—however limited—in place, work can proceed to find the right way to add this functionality into the kernel.

Paris is narrowing in on a design that calls out to user space, both synchronously and asynchronously depending on the operation. File access might go something like this:

open() - causes interested user-space programs to be notified asynchronously; anti-virus scanners might kick off a scan if needed
read()/mmap() - causes a synchronous user-space notification, which allows anti-virus scanners to block access until scanning is complete; if malware is found, cause the read/mmap to return an error
write() - whenever the modification time (mtime) of a file is updated, asynchronously notify user space; this would allow anti-virus scanners to re-scan the data as desired
close() - asynchronous user-space notification; another place where anti-virus scanners could re-scan if the file has been dirtied

Where and how to store the current scanning status of a file is still an open question. Various proposals have been discussed, starting with a non-persistent flag in the in-memory inode of a file. While simple, that would cause a lot of unnecessary additional scanning as inodes drop out of the cache. Persistent storage of the scanned status of a file alleviates that problem, but runs into another: how do you handle multiple anti-virus products (or, more generally, scanners of various sorts); whose status gets stored with the inode?

For this reason, user-space scanners will need to keep their own database of information about which inodes have been scanned. For anti-virus scanners, they will also want to keep information about which version of the virus database was used. Depending on the application, that could be stored in extended attributes (xattrs) of the file or in some other application-specific database. In any case, it is not a problem for the kernel, as Ted Ts'o points out:

I'm just arguing that there should be absolutely *no* support in the kernel for solving this particular problem, since the question of whether a file has been scanned with a particular version of the virus DB is purely a userspace problem.

It is important to keep the scanned status out of kernel purview in order to ensure that policy decisions are not handled by the kernel itself. This is in keeping with the longstanding kernel development principle that user space should make all policy decisions. This allows new applications to come along, ones that were perhaps never envisioned when the feature was being designed. For example, Alan Cox describes another reason that the state of the file with respect to scanning should be kept in user space:

This is another application layer matter. At the end of the day why does the kernel care where this data is kept. For all we know someone might want to centralise it or even distribute it between nodes on a clustered file system.

The latest TALPA design includes an in-memory clean/dirty flag that can short circuit the blocking read notification (when clean). That flag gets set to dirty whenever there is an mtime modification. This optimizes the common case of reading a file that hasn't changed. Further optimizations are possible down the line as Paris mentions:

If some general xattr namespace is agreed upon for such a thing someday a patch may be acceptable to clear that namespace on mtime update, but I don't plan to do that at this time since comparing the timestamp in the xattr vs mtime should be good enough.

Various other uses for the kinds of hooks proposed for TALPA have also come up in the discussion. Hierarchical storage management, where data is transparently moved between different kinds of media, might be able to use the blocking read mechanism. File indexing applications and intrusion detection systems could use the mtime change notification as well. This is a perfect example of kernel development in action; after a rough start, the TALPA folks have done a much better job working with the community.

Some might argue that the kernel development process is somehow suboptimal, but it is the only way to get things into Linux. As the earlier adventures of TALPA would indicate, flouting kernel tradition is likely to go nowhere. While it is still a long way from being included—pesky things like working code are still needed—it is clearly on a path to get there some day, in one form or another.

Comments (48 posted)

Patches and updates

Kernel trees

Linus Torvalds: Linux v2.6.27-rc4. (August 21, 2008)

Steven Rostedt: 2.6.26.3-rt2. (August 22, 2008)

Steven Rostedt: 2.6.26.3-rt3. (August 23, 2008)

Core kernel code

Peter Zijlstra: [PATCH] sched: properly account IRQ and RT load in SCHED_OTHER load balancing. (August 21, 2008)

Manfred Spraul: state machine based rcu. (August 21, 2008)

Paul E. McKenney: scalable classic RCU implementation. (August 22, 2008)

Mathieu Desnoyers: Writer-biased low-latency rwlock v8. (August 22, 2008)

Oren Laadan: kernel based checkpoint-restart. (August 25, 2008)

Daniel Walker: mutex: add mutex_lock_timeout(). (August 26, 2008)

Development tools

Roland McGrath: utrace. (August 27, 2008)

Device drivers

David Vrabel: New subsystems: Ultra-Wideband radio, Wireless USB and WiMedia LLC Protocol. (August 21, 2008)

Sean MacLennan: Pika Warp appliance watchdog timer. (August 23, 2008)

Ron Mercer: New Qlogic 10Gb Ethernet driver for 2.6.28. (August 25, 2008)

Guo-Fu Tseng: jme: JMicron Gigabit Ethernet Driver. (August 25, 2008)

jeykholt@cisco.com: fnic: initial submission of driver for FCoE HBA. (August 25, 2008)

Eric Anholt: Add GEM to i915 DRM driver. (August 26, 2008)

Tejun Heo: sound: make OSS sound core optional. (August 27, 2008)

Greg KH: USB: add USB test and measurement class driver. (August 27, 2008)

Documentation

Michael Kerrisk: man-pages-3.08 is released. (August 27, 2008)

Filesystems and block I/O

Jared Hulbert: AXFS: Advanced XIP filesystem. (August 25, 2008)

Tejun Heo: block: implement extended devt, take #3. (August 25, 2008)

Tejun Heo: block: unify disk/part handling and improve ext devt, take #2. (August 25, 2008)

Kalpak Shah: Large EAs in ext4. (August 26, 2008)

FUJITA Tomonori: convert sg to use the block layer. (August 26, 2008)

Evgeniy Polyakov: Distributed STorage.. (August 27, 2008)

Andrea Righi: cgroup: block device i/o controller (v9). (August 27, 2008)

Security-related

Paul Moore: Labeled networking patches for 2.6.28. (August 25, 2008)

Andreas Gruenbacher: file capabilities: Add no_file_caps switch. (August 26, 2008)

Serge E. Hallyn: selinux: add support for installing a dummy policy (v2). (August 26, 2008)

David Howells: Introduce credentials. (August 27, 2008)

Virtualization and containers

Jeremy Fitzhardinge: [PATCH 0 of 4] Xen spinlock updates and performance measurements. (August 25, 2008)

Eric W. Biederman: sysfs namespace support. (August 25, 2008)

sukadev-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org: : Enable multiple mounts of devpts. (August 25, 2008)

Serge E. Hallyn: User namespaces: introduction. (August 25, 2008)

Benchmarks and bugs

Rafael J. Wysocki: 2.6.27-rc4-git1: Reported regressions from 2.6.26. (August 25, 2008)

Miscellaneous

Karel Zak: util-linux-ng v2.14.1-rc2. (August 23, 2008)

Hans de Goede: Announcing libv4l 0.4.1. (August 26, 2008)

Dave Airlie: DRM development process wiki page... (August 27, 2008)

Page editor: Jonathan Corbet

Distributions

News and Editorials

A new "contrib" repository for openSUSE

By Rebecca Sobol
August 27, 2008

There has been a recent discussion on the opensuse-factory mailing list about the creation of a repository for non-core packages. The concern expressed at the beginning of the discussion is that openSUSE has too many repositories of unknown quality. Right now many openSUSE community members have home repositories with software packages not found in the main openSUSE repository. Some have software that other openSUSE users would like, some have highly experimental packages that most users would rather avoid. It is difficult for the user to find the packages they want, or know which ones they might find suitable. Pascal Bleser expressed some of those concerns:

The goal of the contrib repository must indeed be "stability", which essentially means two things:
- - feature freeze: when the Factory repository is freezed, the contrib repository must be freezed too; only allow bugfix upgrades (as, clearly, I doubt we'd find enough human resources to backport fixes) and reject feature upgrades
- - stable software: packages that are in there need a lot of testing and must hence be picked carefully

The point is to make an "additional" type of repository, not an "always the latest".

And then we should think about how to have those packages tested properly in order to gain an acceptable level of quality in there when openSUSE distro releases happen (or, rather, when they're freezed). Following the alpha/beta/RC cycles of Factory and issue the same calls for testing could be an option.

Alexey Eromenko had some ideas of what that might look like:

Yes, "Contrib" is planned to be a community-driven extension of Factory, with all Factory standards and limits applied.

This means, that user's will have early version of contrib available for 11.1. "early" doesn't mean unstable, but it means that number of packages are expected to be limited.

Only stable software will make it into contrib. All unstable software will remain in user's Home projects in OBS.

Pascal Bleser wondered about how a package is determined to be stable.

Yes, sure, but => "after it becomes stable" <=
That's precisely the point. How do we decide whether a package is stable enough to go into contrib ?
Through a release management team ?
But maybe we need to offer a comfortable way for people to test packages before they make it into contrib, and having a staging repository is one way of doing it.
(I'm just throwing ideas, I'm not saying it's necessarily _the_ way to do it)

Richard Guenther proposed some sort of staging repository.

It as well makes sense to stage Contrib (I would like this for Factory, too, but it's probably easiest to try with Contrib first). If you are familiar with the Debian way then you know there is the unstable and the testing repositories. So there should be something like Contrib:/Unstable (feel free to pick a more suitable name) where a new package (version) should reside for some time before it is migrated to the main Contrib repository. Criterias ideally would be "zero bugs of severity greater than normal" - but of course this would require proper bugzilla integration (or completely manual migration).

Staging Contrib helps getting more peer review and avoids breaking Contrib itself. At the point the next openSUSE is freezed development can continue in the unstable branch but only critical fixes are migrated to Contrib.

Alexey Eromenko that the new repository should have stable versioned branches, but unstable packages should remain in Home repositories.

Speaking about stable/unstable trees: -I think that stable must have braches, yes, (contrib-stable-11.1, contrib-stable-11.2, etc...) - but only for future releases, not backports. Reason is simple: We will find BETA-testers for 11.1/11.2, but unlikely to find enough testers for packages for 10.2.

-unstable: I prefer this branch should exists in user's OBS, but if there are volunteers, it could be part of contrib. Because it is unstable, I don't think it needs branching.

The discussion continued from there. For now unstable packages remain the the user's Home repository and a small review team has been formed to review these potential candidates. The discussion, and results have been documented on the Contrib wiki page, along with a wish list of packages, for those who are interested in learning more about the Contrib repository and the shape it might take.

Comments (2 posted)

New Releases

AntiX 7.5 is Now Available

AntiX 7.5 has been announced. "Built using the MEPIS Linux 7.0 core including the MEPIS 2.6.22 kernel and utilities, along with selected additions from Debian Lenny, this lightweight OS is especially appropriate for older hardware and users who like a very fast and highly configurable system."

Comments (none posted)

BLFS-6.3 has been released

Version 6.3 of Beyond Linux From Scratch has been released. See the release notes for more information.

LWN.net Weekly Edition for August 28, 2008

ipsec-tools: two denial of service vulnerabilities

java: vulnerable versions can be requested by applet

kernel: several vulnerabilities

libxml2: denial of service

openoffice.org: numeric truncation error

tiff: arbitrary code execution

tomcat: multiple vulnerabilities

yelp: format string vulnerability

Events: September 4, 2008 to November 3, 2008