LWN.net Weekly Edition for August 28, 2008

Django nears 1.0 milestone

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:

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

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:

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

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:

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

Inside this week's LWN.net Weekly Edition

• Security: Firefox 3 SSL certificate warnings; New vulnerabilities in java, kernel, openoffice, tomcat,...
• Kernel: AXFS; Sysfs and namespaces; TALPA moves forward.
• Distributions: A new "contrib" repository for openSUSE; new released from AntiX, BLFS-6.3, Debian Live, Fedora Unity, Mandriva and openSUSE
• Development: The SCons build tool reaches the 1.0 milestone, KOffice Summer of Code Ends, Mozilla Ubiquity, new versions of BusyBox, Samba, Pyro, mod_wsgi, Quixote, Tinyproxy, Ecasound, pyspread, YaMA, jCAE, yPlot, KDE, GNU Radio, Kicad, ESS, LedgerSMB, Wine, Elisa, Amuc, Pyrex, Emacs, Pydev, VXL, Bazaar.
• Press: Linux photographic tools, A compilation of Linux text editors, SCO fined in Germany, interviews with Richard Hulse and Jim Zemlin, the kerneloops project, reviews of Acer Aspire One and Intel's Classmate PC.
• Announcements: FSFE on KDE's switch to FLA, Essentia joins OSA, Aptana acquires Pydev, Linux growth rate slows in China, analysis of global Linux usage, Antonio Pizzigati prize nominations, OpenVAS vulnerability contest, Hackers 2 Hackers Conf cfp, IMF cfp, PacSec cfp, Novell Hack Week, Launchpad hosting service, Microsoft patents Page Up/Page Down.

Next page: Security>>