LWN.net Weekly Edition for July 24, 2008 [LWN.net]

GNOME 3.0 worries

By Jonathan Corbet
July 23, 2008

The mood on some GNOME mailing lists in the weeks prior to the recently-concluded GUADEC conference was somewhat somber; some members of the community were clearly feeling that GNOME development had slowed down, that the project lacked vision, and that GNOME was threatening to lose its relevance with users. GNOME subsequently emerged from GUADEC with a new executive director, plans for a 3.0 release, and a new burst of enthusiasm. It's amazing what a week in an exotic city with large amounts of beer can achieve. Since then, however, the enthusiasm has dropped a bit, and work on a proposed 3.0 press release appears to have stalled. GNOME is now faced with some big decisions, and it's not clear what the project will do.

The initial driving force behind this effort appears to be a plan by the developers of the GTK+ toolkit to move to a new ABI without concerning themselves with backward compatibility. Years of enforced ABI stability have left GTK+ with a large pile of compatibility cruft which the developers would like to leave behind; in addition, there are major changes planned which would be hard to do in a backward-compatible mode. So the GTK+ developers would like to start over with a 3.0 release. Lots of planning is being done to make the transition easy; among other things, care will be taken to ensure that GTK+ 3.0 will coexist nicely with older installations. But, in the end, it's an incompatible ABI change.

At this point, the loudest objections seem to come from Miguel de Icaza. He fears that a new version of GTK+ will leave independent system vendors behind and, perhaps, lead to a series of ABI-breakage events. In particular, Miguel takes issue with the plan to make the ABI changes for the GTK+ 3.0 release, and only add the new features (which, like much of the GNOME 3.0 plan are somewhat fuzzy at the moment) later. The needed new features, he says, should be driving the whole process. And, if at all possible, those features should be added in a way which does not require an ABI flag day.

It would appear that the GTK+ developers are determined to make this change, though, so expect it to go forward. But a GTK+ change is not the same as a GNOME change; there is no particular need for GNOME to make a major release just because an important library it uses has done so. Anybody who has looked at the linkage of a GNOME application knows that GNOME uses a lot of libraries; they cannot all drive major GNOME releases. So, one might ask, what is happening with GNOME in particular that warrants a 3.0 release?

This question was, arguably, most eloquently asked by Luis Villa, who has described GNOME 3.0 as "a terrible idea." Luis's point is that an ABI change is not enough to motivate a major release; instead, there must be a fundamental vision of a better way to do things. That vision, he says, is not there now. This is not an unprecedented situation in the GNOME community:

2.0 almost failed for this exact reason- before there was a clear vision about doing usability/simplicity-centered design, the new version number was a huge invitation to insert $VISION here, leading to all kinds of crack.

A 3.0 process without a clearly-articulated vision will invite the same sort of "crack." It will also throw away the rare public relations opportunity that comes with a major update:

Finally, from a media perspective: the reason GNOME 2.0 was a success in the Linux media, and the reason KDE 4.0 has been a failure, is that GNOME 2.0 had a clear, persuasive story around it: simplification and usability. No one in the media cared that we had a new toolkit, except where it had specific features (mainly i18n) that had user benefits. Writers ate up our usability story- they could tell their readers the story we put out there, and it made sense to them. KDE 4 has no coherent user-focused story, so this incredible opportunity to reach out to the press has been squandered.

There are, certainly, interesting ideas to be found in the GNOME community. The online desktop ideas, Document-centric GNOME, and the mobile initiatives are examples. But it is true that nobody has, yet, put together a concept of GNOME 3.0 which is broad enough to unify and direct all that work while simultaneously being concise enough to fit onto a bumper sticker. Chances are good that most GNOME developers do not know what GNOME 3.0 really means; those outside of the development community will have even less of a clue.

The KDE 4.0 experience should be on the GNOME project's collective mind as it ponders a possible 3.0 release. Future KDE users may see KDE 4.0 as the turning point where their desktop started becoming truly great, but, for now, it does not look like a whole lot of fun for the KDE development community. GNOME developers, one assumes, would prefer not to have a similar experience.

GNOME 2.x has been around for some time; it may well be true that it is time to make a big jump. It would be gratifying to see some new energy and directions from the highly creative GNOME development community. If the project can come up with a set of overall goals which can inspire that community toward a set of common ends, GNOME 3.0 could be a spectacular success. But those goals, if they exist, have not been communicated to the community yet, and that is making some GNOME developers nervous.

Comments (26 posted)

Anticipating the sunset

By Jonathan Corbet
July 22, 2008

In his two years at the top of Sun Microsystems, Jonathan Schwartz has embraced a number of ambitious changes. While one need not look too far to find complaints about how Sun works with the free software community, there can be no doubt that Mr. Schwartz has made the company far more open than it was in the past. Free software is an important part of Sun's overall strategy; this can be seen in the company's claims to have contributed more code to the community than any other source.

Unfortunately, Mr. Schwartz's time at Sun has been accompanied by a 50% decline in Sun's stock price. Whether he could possibly have done any better given the state of the company when he took over and state of the economy now is something one could debate, but we'll not do that here. More interesting, from the community's point of view, is the rumors that he could soon be looking for a new job.

It has often been said that if corporations were people, they would have the personality of a sociopathic teenager. Certainly companies can exhibit no end of the sort of moody, capricious, and even self-destructive behavior sometimes seen in adolescents - then they come back and ask for more money. An abrupt change at Sun could well bring in a CEO determined to show that his predecessor's policies were fundamentally wrong and were primarily responsible for Sun's problems. And that could bring some interesting changes.

Imagine a Sun which decided that it could no longer afford to share its Valuable Intellectual Property with the world. Perhaps Solaris, OpenOffice, Java, etc. would be relicensed under the new, Sun Proprietary Overtly Indecent License (SPOIL), with no more free releases. Hungry lawyers could start prowling for cases where Solaris code has been mixed into projects with incompatible licenses. StarOffice might go OOXML-only. MySQL could shift to a new, undocumented on-disk format with users' data subject to Sun-controlled DRM on every table. The new Java license would forbid the publication of not just benchmark results, but also of criticism of features of the language.

Clearly, some of these scenarios are rather far afield - though they are fun to make up. But, if we have learned anything from the SCO story, it must be that a company which presents itself as a solid part of the community can, in short order, turn around and go against us. Even if Sun does not degenerate to the point of starting legal attacks against free software, it could certainly put an end to the many contributions that it is making now.

Whenever one deals in company-owned free software, one should consider what happens if that company goes away. Projects with distributed copyright ownership are mostly immune to this kind of problem; there is no single company which could create huge problems for the Linux kernel by withdrawing its participation, for example. (Along these lines, it's worth noting that Evolution recently stopped requiring copyright assignments from its developers). But, in situations where a single company owns the copyrights and dominates development, a change of heart could make a real difference to downstream users. It all depends on what sort of community has developed around the code.

If future versions of Solaris were to be proprietary-only, the current releases would still be out there. But the Solaris development community outside of Sun is tiny, so chances are good that such a move would kill OpenSolaris as a free software project - to the extent that it is one now. Anybody wishing to continue to use Solaris would probably have to move to the proprietary version. OpenOffice.org would likely survive, though the external development community - never encouraged that much by Sun - would have to organize itself and, perhaps, choose a new name. Java is entirely subject to Sun's policies regarding conformance tests and such; it could easily revert to its status from a few years ago. And so on. The point is that a change of heart at Sun could easily make us appreciate the company's relatively friendly attitude now, and could create difficulties for distributors and users of Sun-sponsored projects.

There are plenty of other single-owner projects out there, of course. Many of them are entirely dependent on the continued good will (and viability) of their sponsoring companies. Others are less so. Copyrights on code released by the GNU project are generally owned by the Free Software Foundation. But, if Richard Stallman were to hit his head in an unfortunate contra dancing accident and decide that, henceforth, FSF-owned code would only be released under the binary-only GPLv4, those projects would not suffer much. Instead, the development community behind that code - strongly influenced but not controlled by the FSF - would quickly move to a new home and continue its work. For a practical example, see the creation of X.org in the wake of the relicensing of XFree86.

With any luck at all, the silly scenarios outlined above will not come to pass. But there is value in pondering how things could go. Such thought quickly leads to the conclusion that a vibrant development community is not just good because it leads to faster progress and more cool features. That community is the source for the long-term support for the code, support which is not subject to one company's quarterly results.

Comments (19 posted)

Interview: Wind River's John Bruggeman

July 21, 2008

This article was contributed by Glyn Moody

If you wanted a symbol of Linux's impact on the world of embedded systems, you could do worse than consider the edifying case of Wind River's Damascene conversion. Once one of free software's fiercest critics, today Wind River is a cheerleader for the benefits of open source, of sharing, and of giving back to the community.

John Bruggeman is Wind River's Chief Marketing Officer. Here he talks to Glyn Moody about why you can't use any old Linux for embedded systems, the respective strengths and weaknesses of the Linux-based mobile platforms from the LiMo Foundation and Google's Android, and what effect Nokia's announcement that it would be open-sourcing the Symbian operating system will have on the sector.

Once upon a time, Wind River was synonymous with anti-Linux: what happened?

The market changed, and I think that open source became a very, very important part of the addressable market we wanted to reach. And if Wind River was going to be relevant and going to be important in the marketplace, we would have to have an open source and specifically a Linux-based solution for our customers. So, basically, the market thrust us into it, demanded that we do it, and I think it was all for the best that that happened.

What do you have to do to Linux to make it suitable for the embedded market?

The embedded marketplace has requirements that aren't in the general enterprise computing market. Things like size becomes very critical, and memory utilization and power management and some other features like that. Standard Linux wasn't optimized or suited for device types that face those challenges.

Those are kind of software elements, but there is also a hardware element. In the enterprise computing space, you are basically living in an [Intel architecture] world and everything is pretty constant and stable and predictable. Well, that is the anti-case with what we see in embedded. You have a plethora of hardware environments. Each hardware environment has their own specific nuances and special techniques and tips and trips. And making Linux work really well with hardware is a tough problem.

How would you compare your Linux offering with your proprietary VxWorks solution?

VxWorks is where you need absolute real-time determinism, where you need things like safety and security, [and to] meet certain regulatory standards and certification standards: those kinds of applications are the sweet spot for our VxWorks software. More general solutions, where application availability, middleware integration, [and] where lots and lots of ecosystem partners are required, that's in the sweet spot of our Linux software.

Is there any reason why your Linux software couldn't take on the other kinds of things as well?

I think, over time, probably not. But, that's a long time way. A great example of that would be security certification for an airplane. The standards and the requirements to meet those certifications are very, very complex. They are very difficult and I think Linux is a long way away from being able to do that.

What's the kind of split between the VxWorks and Linux, in terms of revenue?

Today about 80% of our revenue is VxWorks, but the fastest-growing segment of our business is Linux. It's growing in the triple digits quarter over quarter over quarter. We announced it well north of $50 million for us this year.

Do you think one day you'll ever be wholly open source?

Wholly? I don't think so. There will always be certain types of devices in which VxWorks will be a superior solution. But the Linux portion of our business will continue to grow, and I see a day where our Linux business is every bit as big as the VxWorks business.

What are the key attractions of Linux for your customers?

Let me start with Linux in general. The first is availability of the ecosystem. The need to accelerate the pace of development is becoming critical. Many, many of our customers used to be vertical integrators - they even manufactured their own silicon and they would go all the way up to the top. And we're seeing a change that's happening at light speed, where they are shifting from a vertical integrator to an application developer. And they are really differentiating themselves on the user experience, on the type of applications they develop.

The attraction of Linux is there's this massive development community developing that infrastructure stuff that they used to spend so much time on, that enabled application development: they don't have to do that anymore. The second thing is obviously cost. They really can get it at a significantly lower development cost than they did when they used to have to build it themselves.

What's your business model?

We provide things like integration testing and validation. Open source is a bunch of packages and the magic is how well are they put together and how reliable are they, and how well has that been tested, and can you validate and stand behind that? We have over 300 support engineers located globally around the world, in different time zones. We have the richest indemnity and warranty program in the industry. We don't stand behind Wind River, we stand behind open source.

Moving on to the mobile phone space, can you say a little about LiMo and Android, and what your involvement in those has been?

Linux has the opportunity to revolutionize the mobile phone space - not just smart phones, but feature phones, converged phones, [Mobile Internet Devices - MIDs]. What's holding it back right now is the fragmentation. There are just way too many different Linux distributions. What that means is the ecosystem can't aggregate and surround anything of any critical mass. So, two initiatives have broken out that seem to be aggregators or consolidators: one is LiMo and one is Android. We're not smart enough to know which one is going to be the ultimate consolidator, so we're tremendously active in both.

We joined LiMo as a board member and we work very, very hard with the architectural committee to become the Linux foundation for all LiMo-based development. What that means is the common integration environment, which is the Linux-built system, the tool chain, is all based on Wind River technology. And therefore any contribution that's made to LiMo [is] based on our technology - we contributed that common integration environment to the LiMo foundation.

[Open Handset Alliance's Android] was announced about six or nine months or so after LiMo, and Google came out and said Wind River is their Linux commercialization partner. We have been working with them for about two years. We've done a number of hardware integrations for them. That's one of our core competences: how do you get Android running on the hardware.

We have phones coming out for both. We see a lot of activity on both and a lot of momentum for both.

How would you contrast the two initiatives?

LiMo truly is a consortium of equals. There are multiple operators: Vodafone, Docomo, Verizon, Orange, others. A bunch of carriers and a bunch of handset OEMs: Motorola, Samsung, LG, Panasonic, NEC. And the board is made up of those guys and Wind River. And we see that really is sort of: how do we get a common ground between fierce competitors? How do we, for the good of the industry, standardize around that stuff that's non-differentiating?

OHA is really a Google-driven initiative. They make product decisions and they make feature decisions.

So, let's talk pros and cons about this. When it's not a democracy, when the decision-making is very clear, decisions can be made quickly and things move very fast. On the LiMo side, where it's a lot of people, with a lot of experience building phones, who know what really matters, and what's important and what works and what doesn't work, they can bring a lot of different experience, a wealth of different perspectives together.

Sometimes it might take a little longer to make a decision over here but I really understand and can see why that decision works over there. Where this one races ahead, this one's a little more methodical and carefully constructed. But they're both building compelling platforms and will both be successful in the marketplace.

Alongside LiMo and Android, we will have an open source Symbian at some point; what effect is that going to have on this whole market?

If you look at the smartphone market, it's 7% today of the total phone marketplace. So, from a percentage basis, it's not big. But what we're seeing is more and more feature phone-like capabilities blurring with the smartphone. So even though it's a small part of the market today, it's very strategic, because it does have implications down-market on the feature phones.

Symbian's got 60% of the smartphone market. And Microsoft's 20 to 30% of that market. Certainly they are not among equals, but Microsoft's been gaining share against Symbian and against Nokia. So, I think this was an aggressive and a bold and clever move against Microsoft.

Vis-a-vis Linux, the Symbian move just endorsed what was going on. It said if you're going to be competitive, if you're going to relevant years from now, you'd better have an open source model. I love that endorsement of Linux.

On the other hand, their solution is years away. Nokia said: Well, we'll have it in the first half in 2010. Both Android and LiMo will have phones out by the end of this year. So, there should be a lot of activity. Now if I'm an ecosystem member, am I going to wait for 2010, or am I going to develop today, and address real design opportunities and real win opportunities today?

I think Linux has a window of opportunity. We're going to see mass adoption of Linux-based devices, whether they are phones, or converged devices or MIDs, or whatever they are. However this market evolves, Linux is going to have two years' worth of product out there in the marketplace, doing stuff, before we see Symbian open source. While Nokia made a brilliant and bold move, it might be too late, because there is enough Linux momentum, especially behind OHA and LiMo, that I think they left that too long.

What about the other player in the closed-source world, Apple with its iPhone?

Apple will always be what Apple is. Apple is just fantastic, touches the super, niche, high end - somebody willing to pay $700 for a phone. And there is a big market for that - if you think a big market is 10 million phones. That's going to be there and that's not threatened or messed with in any of this stuff, because they are always going to come out with some really creative form factor or killer application: they are going to touch 10 million people. Three years from now we'll see a couple billion phones in the marketplace. So, let Apple go be content with that [10 million]. Let RIM go hit their niche part of the market. I don't see that catching fire.

So you've got the smart phones, the MIDs and now these ultraportables - the $300-400 machines that run GNU/Linux. How do you see that three-way contest panning out?

I think all three devices meet certain use cases. I don't see, in the near future, or even the mid-term future, a MID overtaking a phone. There's a reason people talk on phones, but there's this whole different class of people in different use scenarios, they need a MID.

What is becoming very, very clear is, it's not about voice and it's not about text or email, it's going to be about a true, rich Internet experience. Can a web page be represented on these devices at the same clarity, the same quality, the same speed, as they are on the PC? When I look at YouTube, I don't want to look at a fuzzy, webcam image. I want to see [High Definition] quality on that thing. So, the devices we're seeing today, they're being required to be able to deliver that level of video representation and audio, that's [as good as] my music device and that's as good as my home entertainment system.

In what other embedded sectors Linux becoming important?

One of the fastest-growing areas of Linux we see right now is in the automobile: in the in-vehicle entertainment, in the dashboard, in the navigation. Those, for years and years and years, have been relegated to proprietary software stacks, because there's this big stigma that an automobile is hard. It moves and it bumps and there's temperature and there's all these safety requirements, and that's proprietary stuff.

I think Apple helped change the game, because everybody wanted their iPod in their car without a bunch of wire striking around. Automobile manufacturers worked on the development cycle that is five to seven years, and all of a sudden the iPod hits and they have one quarter to figure out how to get that thing in there.

This is a whole new business and process problem that the automotive manufacturers had not been in before. They all stood up and said: We don't know how to do this. And then the next new application came in and the next new application and, all of a sudden, they said: There's been a tremendous disruption in the industry; we've got to change the underlying principles how we design these applications. And Linux is clearly the solution for that, because it's all about the application and how extensible can the platform be, and how well can we count on consumer-like speed in an automotive-like marketplace.

The second market that I would say we're seeing in the home. Things like broadband access points - how you get content into the house: that's going Linux now. Every new data standard, Linux is keeping pace with that better than anything else out there.

We're seeing a general theme here. There's a real need for content - I want YouTube and I want cable and I want satellite and I want data. We're seeing those three C's of content, of connectivity, and of complexity. When you have those three things there, Linux is a tremendous solution.

Glyn Moody writes about open source at opendotdotdot.

Comments (13 posted)

Page editor: Jonathan Corbet

Security

Deep packet inspection

By Jake Edge
July 23, 2008

At its core, the internet is a set of agreements; not just on protocols, but also on practices amongst carriers. Part of what has allowed the explosive growth—in both participants and services—of the internet can be attributed to these agreements. When a new technology like deep packet inspection (DPI) comes along to threaten these long-standing practices, it should be cause for concern.

Internet packets are constructed much like postal mail. There is an envelope with addressing information contained in the packet header and a message which is contained in the data payload portion of the packet. Internet carriers are supposed to make their best effort to deliver a packet based on the information in its header. DPI violates that compact by looking inside the data portion, as the packet is en route to its destination, and making decisions based on that.

There are some potentially valid uses for DPI—network performance monitoring and law enforcement surveillance, perhaps even with a warrant, are two—but the potential for abuse is large. Because network processing has gotten to the point where devices can do more than just observe and record, packets are being modified and generated on-the-fly in a technique known as deep packet processing (DPP).

Various examples of DPI and DPP—generally lumped together as DPI—have been in the news over the last year. Comcast used DPI to try and throttle Bittorrent traffic, while Phorm and NebuAd have used it to rewrite web pages to deliver advertising to unsuspecting users. The DPI problem has gotten enough attention that even various governments have started showing interest.

The designer of User Datagram Protocol (UDP)—the connectionless analog to Transmission Control Protocol (TCP)—David Reed recently testified to the US Congress about DPI. In his testimony [PDF] he outlines numerous technical issues, but the biggest may lead to breaking the fundamental model of internet communication:

This is the real risk: [a] service or technology unnecessary to the correct functioning of the Internet is introduced at a place where it cannot function correctly because it does [not] know the endpoints' intent, yet it operates invisibly and violates rules of behavior that the end-users and end-point businesses depend to work in a specific way.

We have seen this behavior from internet companies in other guises as well. Verisign and various ISPs have tried redirecting failed DNS queries to pages they control (and generally fill with ads). Once again, that breaks many applications; it functions more or less correctly for web browsing, but other applications depend on receiving proper errors when querying for nonexistent domains.

Because many ISPs hold a near-monopoly on high-speed access in a particular geographical area, they can hold their customers hostage with little concern that competition will come along to force a change. It is this abuse of their monopoly position that tends to interest regulators. In addition, most of their customers are unlikely to notice these "enhancements", making it easier to get away with—at least until those more technically savvy recognize and raise the issue.

Using encrypted communications, HTTPS for web browsing for example, is one defense against DPI. There is some cost associated with encryption, of course, but it is one that is likely to be borne if internet carriers persist in these shenanigans. Another option might be Obfuscated TCP, which is a technique to do backwards-compatible encryption at the packet level. Because it doesn't require all hosts to support it at once—it is negotiated between the endpoints when the connection is established—it could incrementally be added into the arsenal of tools to thwart DPI.

DPI uses techniques that have generally been attributed to the "cracking" community. Things like man-in-the-middle attacks and IP address spoofing are difficult-to-solve security problems for many applications. When the "legitimate" middlemen start manipulating packets using these means for their own benefit, they come very close to—or cross—the line into illegality.

This is a battle about control; our freedoms to communicate and innovate on the internet are at stake. A phone system that randomly inserted advertising into calls or a postal system that kicked back letters whose contents it didn't like as undeliverable would not be considered functioning systems. The internet requires the same treatment.

Comments (8 posted)

Security reports

Fortify: open source software is a security risk for businesses

Fortify Software, a vendor of security scanning solutions, has put out a press release saying that open source software poses security risks for businesses, partly as a result of the lack of use of security scanning solutions. There is an associated report available for those who register. "The survey, sponsored by Fortify Software and completed by leading application security consultant Larry Suto, examined 11 of the most common Java open source packages. In order to evaluate the security expertise offered to users and to measure the secure development processes in place in OSS communities, Fortify interacted with open source maintainers and examined documented open source security practices."

The whole thing may be self-serving, but there is also a real point: anybody contemplating putting software into a security-relevant setting should look at how the project handles security issues.

Comments (17 posted)

New vulnerabilities

afuse: privilege escalation

Package(s):

afuse

CVE #(s):

CVE-2008-2232

Created:

July 17, 2008

Updated:

August 21, 2009

Description:

From the Debian alert: Anders Kaseorg discovered that afuse, an automounting file system in user-space, did not properly escape meta characters in paths. This allowed a local attacker with read access to the filesystem to execute commands as the owner of the filesystem.

Alerts:

Fedora	FEDORA-2009-8792	2009-08-20
Fedora	FEDORA-2009-8816	2009-08-20
Debian	DSA-1611-1	2008-07-16

Comments (none posted)

bacula: password disclosure

Package(s):

bacula

CVE #(s):

CVE-2007-5626

Created:

July 22, 2008

Updated:

August 27, 2012

Description:

The Bacula backup utility can disclose passwords via process listings and plain-text email. See this bug entry for details.

Alerts:

Gentoo	200807-10	2008-07-21
Fedora	FEDORA-2012-11717	2012-08-27

Comments (none posted)

bitchx: boundary error and temporary file vulnerability

Package(s):

bitchx

CVE #(s):

CVE-2007-4584 CVE-2007-5839

Created:

July 22, 2008

Updated:

July 22, 2008

Description:

The bitchx IRC client suffers from a boundary overflow vulnerability (CVE-2007-4584) and a temporary file vulnerability (CVE-2007-5839). It also suffers from a lack of maintenance, so switching to a different client might be a good idea.

Alerts:

Gentoo

200807-12

2008-07-21

Comments (none posted)

kernel: null pointer problems

Package(s):

kernel

CVE #(s):

CVE-2008-2812

Created:

July 21, 2008

Updated:

December 17, 2008

Description:

Some TTY devices do not check for NULL function pointers before calling them. On most systems, these devices are only accessible to the root user.

Alerts:

CentOS	CESA-2008:0973	2008-12-17
Red Hat	RHSA-2008:0973-03	2008-12-16
SuSE	SUSE-SR:2008:025	2008-11-14
SuSE	SUSE-SA:2008:052	2008-10-21
SuSE	SUSE-SA:2008:049	2008-10-02
SuSE	SUSE-SA:2008:047	2008-10-01
Ubuntu	USN-637-1	2008-08-25
Debian	DSA-1630-1	2008-08-21
CentOS	CESA-2008:0612	2008-08-06
Red Hat	RHSA-2008:0612-01	2008-08-04
SuSE	SUSE-SA:2008:038	2008-07-29
Red Hat	RHSA-2008:0665-01	2008-07-24
SuSE	SUSE-SA:2008:037	2008-07-22
SuSE	SUSE-SA:2008:035	2008-07-21

Comments (none posted)

kernel: privilege escalation

Package(s):

kernel

CVE #(s):

CVE-2008-3247

Created:

July 22, 2008

Updated:

October 23, 2008

Description:

The kernel (on x86_64 systems only) used an incorrectly-sized buffer in LDT handling, leading to a potential local privilege escalation; this vulnerability was introduced in 2.6.25.

Alerts:

Fedora	FEDORA-2008-8929	2008-10-23
Fedora	FEDORA-2008-8980	2008-10-23
SuSE	SUSE-SA:2008:037	2008-07-22

Comments (none posted)

libxcrypt: incorrect hash algorithm used

Package(s):

libxcrypt

CVE #(s):

CVE-2008-3188

Created:

July 21, 2008

Updated:

August 8, 2008

Description:

libxcrypt can use DES to encrypt passwords when the administrator has selected MD5.

Alerts:

SuSE	SUSE-SR:2008:016	2008-08-08
SuSE	SUSE-SA:2008:036	2008-07-21

Comments (none posted)

mantis: multiple vulnerabilities

Package(s):

mantis

CVE #(s):

CVE-2008-2276

Created:

July 23, 2008

Updated:

September 22, 2008

Description:

The mantis bug-tracking system has a number of bugs of its own, including cross-site scripting, cross-site request forgery, remote code execution, and arbitrary file inclusion. Version 1.1.2 has the fixes.

Alerts:

Gentoo	200809-10	2008-09-21
Fedora	FEDORA-2008-6647	2008-07-23
Fedora	FEDORA-2008-6657	2008-07-23

Comments (none posted)

ruby: integer overflows

Package(s):

ruby

CVE #(s):

CVE-2006-2662

Created:

July 22, 2008

Updated:

July 28, 2008

Description:

The Ruby string processing code contains multiple integer overflows which can be exploited in a denial of service attack with the potential for the execution of arbitrary code.

Alerts:

Debian	DSA-1618-1	2008-07-26
Debian	DSA-1612-1	2008-07-21

Comments (1 posted)

Page editor: Jonathan Corbet

Kernel development

Brief items

Kernel release status

The 2.6.27 merge window remains open, so there is no 2.6 development kernel release as of this writing. Patches continue to flow into the mainline repository; see the summary below for the highlights.

The 2.6.25.12 stable update is in the review process as of this writing; it should be released sometime around July 24. The proposed update contains 47 patches implementing a wide variety of fixes.

Comments (none posted)

Linus's mid-merge-window reflections

Linus has sent out an announcement that the 2.6.27 merge window is halfway done, and that he's taking a break for a few days. "In the last couple of days I _have_ merged 50+ trees, and while there's been some 'heated discussion' about some of them (you know who you are ;), I'm hoping that we're actually in reasonably good shape even though it's in the middle of the merge window, and that people will test out the snapshot kernels even though I'm not ready to do a -rc1 release."

Full Story (comments: 9)

Kernel development news

Quotes of the week

There is no more distributed storage you knew before, instead there is completely new project being developed, which main goal is to provide a transport layer for the block requests only. Consider it as Network Block Device on huge steroids. Consider it as iSCSI on huge steroids. Consider it as ATA-over-Ethernet on even more huge steroids. It is just an example of what all those protocols should have. And only that.

-- Evgeniy Polyakov didn't get the "zero tolerance for doping" memo

If you want the kernel people to endorse your project, you'll have to please them. Its that simple. If that means having to radically re-structure your design, and/or break backwards compatibility then so be it. Such are the costs for not collaborating from the start.

If you stubbornly refuse to co-operate you'll either break the project or invite a fork/rewrite by someone else if the idea is deemed worthwhile enough.

-- Peter Zijlstra (on SystemTap)

Being a good citizen in Linux land often means improving whole subsystems rather than stuffing a bunch of fancy features into individual drivers. Working that way can be harder, but it spreads the benefits wider, and improves Linux as a whole.

-- Jesse Barnes

FWIW, I would rather see implications thought about *and* mentioned in the changelogs. OTOH, the above shows the real-world cases when breakage hadn't even been realized to be security-significant. Obviously broken behaviour (leak, for example) gets spotted and fixed. Fix looks obviously sane, bug it deals with - obviously real and worth fixing, so into a tree it goes... IOW, one _can't_ rely on having patches that close security holes marked as such. For that the authors have to notice that themselves in the first place.

-- Al Viro (read the whole thing)

Comments (5 posted)

More quotes of the week

Code cleanups sometimes expose fundamental disagreements about how the code should look; here some veteran kernel hackers show how it's done.

Rusty, in his peevish way, complained that macros defining constants should have a name which somewhat accurately reflects the actual purpose of the constant.

Aside from the fact that PTE_MASK gives no clue as to what's actually being masked, and is misleadingly similar to the functionally entirely different PMD_MASK, PUD_MASK and PGD_MASK, I don't really see what the problem is.

-- Jeremy Fitzhardinge

Has Rusty ever heard about the economy of the healthy flow of incoming regressions? What will we do without obscure names and hard to find bugs? First he writes a simple and readable hypervisor (ruining a whole industry based on obscurity!) and now that. It's _so_ unamerican and unaustralian. I'm worried.

-- Ingo Molnar

I am disgusted with this inappropriate emphasis on clarity over obscurity. It should be pretty clear to everyone here that we can't have both! Fortunately, there is a way to partially rectify the situation. Ingo, please apply.

[...]

+/* There's something suspicious about this line: see PTE_PFN_MASK comment. */
 #define __PHYSICAL_MASK ((phys_addr_t)(1ULL << __PHYSICAL_MASK_SHIFT) - 1)
 
@@ -19,6 +20,7 @@
 
 /* PTE_PFN_MASK extracts the PFN from a (pte|pmd|pud|pgd)val_t */
+/* This line is quite subtle.  See __PHYSICAL_MASK comment above. */
 #define PTE_PFN_MASK		((pteval_t)PHYSICAL_PAGE_MASK)

-- Rusty Russell

Comments (3 posted)

2.6.27 merge window, part 2

By Jonathan Corbet
July 23, 2008

As of this writing, just over 6200 changesets have been merged into the mainline git repository since the 2.6.26 release. Merge activity appears to be slowing down somewhat; it appears that most of the major trees have been pulled. Andrew Morton has not yet started to unload the -mm tree into the mainline, though; until that happens, the merge window can be expected to remain open.

User-visible changes merged since last week's summary include:

There are new drivers for Samsung S3C SD/MMC interfaces, Atmel Multimedia card interfaces, Ricoh Bay1Controller cards, S/390 QDIO controllers, Renesas SuperH SH7710 and SH7712 Ethernet controllers, Option HSDPA/HSUPA mobile network devices, Broadcom BCM57711 Ethernet adapters, Mikrotik RouterBoard 532 series boards, Anysee DVB-T/C USB2.0 receivers, Sensoray 2255 video capture devices, Siano SMS10xx digital television devices, SuperH Mobile CEU camera controllers, Niagara2 hardware random number generators, HTC Shift (X9500) touchscreens, iNexio serial touchscreens, Sahara TouchIT-213 touchscreens, Xilinx XPS PS/2 controllers, Maxim MAX7301 GPIO expanders, HP iLO/iLO2 management processors, Atheros L1E Gigabit Ethernet adapters, Marvell XOR DMA engines, Synopsys DesignWare DMA controllers, and Intel version 3.0 I/OAT DMA engines. There is also a new PCI "slot detection driver" which will attempt to find all PCI slots in the system and create corresponding entries in /sys/bus/pci/slots/.
Worthy of note: the "gspca" set of video drivers, long maintained outside of the mainline kernel tree, has been merged. These drivers support a large number of video devices; with their merge, most video camera devices on the market are supported by Linux.
The Fujitsu laptop driver has been updated with better hotkey and backlight support for more Fujitsu models.
The UBIFS filesystem for flash-based storage devices has been merged.
The multiqueue networking patches have been merged.
The IA-64 architecture has gained a paravirt_ops implementation to support virtualization.
The new directories found at /sys/dev/char and /sys/dev/block contain pointers to sysfs entries for devices organized by device number.

Changes visible to kernel developers include:

The new suspend and hibernate infrastructure has been merged, providing a wider set of callbacks for power management events. The PCI and platform bus interfaces have been enhanced with support for this new infrastructure.
The TTY layer continues to evolve; significant changes include the introduction of a new tty_port structure meant to hold information common to all TTY ports and a rework of the line discipline code.
The mac80211 code has a new module which can simulate any number of IEEE 802.11 radios; it is suitable for testing mac80211 functionality and associated user-space tools.
There is a new "rfkill" mechanism for unified handling of "radio off" switches on wireless devices.
A number of Video4Linux2 format-related callbacks have been renamed to make them match the names used with the associated buffer types. In addition, the vidioc_enum_fmt_vbi_cap() callback has been deprecated and marked for removal in 2.6.28.
The videobuf layer now has support for controllers which cannot do scatter/gather I/O.
The USB "gadget" framework has been massively reworked to provide better support for composite devices.
The prototype for device_create() has changed:
```
    struct device *device_create(struct class *class, 
                                 struct device *parent,
			         dev_t devt, 
				 void *drvdata, 
				 const char *fmt, ...);
```
Those who see a resemblance to device_create_drvdata() are right; all in-tree users were converted over to that interface, the old device_create() was removed, and device_create_drvdata() was renamed. For now, a macro makes calls to device_create_drvdata() do the right thing, but that macro will probably go away before the 2.6.27 final release.
User-space UIO drivers can now write a signed value to the /dev/uioX device to enable and disable interrupts.
Debugfs (finally) has a function for removing an entire directory tree:
```
    void debugfs_remove_recursive(struct dentry *dentry);
```
As a result, code creating hierarchies in debugfs no longer need remember the dentry of every file they create.

The tail end of the 2.6.27 merge window will be covered in next week's LWN Kernel Page.

Comments (none posted)

Linux-next meets the merge window

By Jonathan Corbet
July 23, 2008

Recent LWN articles on the linux-next tree have noted that, while this tree has been working well in its role of identifying merge conflicts between subsystem trees, it has not yet been through a full kernel development cycle. 2.6.27 will be the first kernel release where linux-next was in existence for the entire preceding cycle; in theory, everything which goes into 2.6.27 should have been aged in linux-next first. As the end of the 2.6.27 merge window nears, a look at how linux-next has affected the process seems warranted.

One might think that linux-next maintainer Stephen Rothwell would be able to take a break during the merge window; it should mostly be a matter of watching the linux-next tree drain into the mainline. As it happens, the daily linux-next postings (example) suggest a fair amount of scrambling to deal with merge conflicts, build failures, and more. There are a number of reasons for this, one of which being that subsystem trees are merged into the mainline in an order which is completely unrelated to their order in linux-next. Patches which remain in linux-next are being applied to a highly unstable base.

Another interesting phenomenon has been a fair number of patches appearing in linux-next during the merge window. Some of these are actually patches intended for 2.6.28; once maintainers have dumped their 2.6.27 patches into the mainline, they are starting to acquire stuff for the next time around. Stephen has asked them not to do that, requesting that 2.6.28 material not be directed toward linux-next until after the 2.6.27-rc1 release. The goal is that linux-next should be nearly empty when 2.6.27-rc1 comes out.

Other patches, though, are intended for 2.6.27 but simply have not done their time in the linux-next tree. That had led to a certain amount of developer grumpiness at times. It is interesting to note, though, that one of the biggest examples of linux-next avoidance - David Miller's merging of the multiqueue networking code which he had finished writing hours before - has generated relatively few complaints. But various other types of conflicts have generated a steady steam of terse notes from Andrew Morton (who is in the unfortunate position of basing his work on top of linux-next) on how new stuff should have been in linux-next weeks ago.

Another area of, say, colorful conversation has been around the TTY subsystem, currently been subjected to a much-needed thrashing by Alan Cox. Some developers have been unhappy with Alan for merging code which failed to compile, even though those problems had already been identified in linux-next. Alan, instead, has become irritated with other developers who have surprised him with TTY-layer changes of their own, causing Alan's patches not to apply. Alan has some quaint notions about actually testing his patches, so the resolution of this kind of conflict requires the running of a new set of regression tests and such; after this had happened a few times in a row, he started getting a little short-tempered. These issues would appear to have been worked out at this point, but the idea behind linux-next was to keep them from happening in the first place.

Yet another source of occasional merge issues is the rebasing of trees. Rebasing, in git-speak, is the process of modifying the commit history in a repository to cause a series of patches to look like they were written against a later version of the code than they really were. Rebasing can be a useful technique; it generates a series of patches which applies cleanly to the current state of the tree without generating a bunch of unsightly merge commits.

Rebasing can be especially useful in the context of linux-next. If testing turns up a patch which breaks the build, simply committing a fix will leave a period in the history where the kernel cannot be built, and that is bad for people running bisections. With the use of git's history editing features, the offending patch can be fixed in place and all evidence of the mistake disappears. In essence, that embarrassing commit mentioning the Eurasian campaign can be fixed up to properly note that we've always been at war with Eastasia.

But rebasing a repository changes the history (by design), creating, in the process, an entirely new set of commits. Those commits are new code, to the point that any results from testing the older version may no longer apply. The commits also have new names, so any other developer who was using a version of the repository will be shaken off and unable to merge. Issues related to rebasing have come up a couple of times during the merge window, leading Linus to post a series of lectures on the problems that rebasing can cause. It is clearly a tool which must be used with restraint, but occasional use of rebasing can, in the linux-next context, lead to a better final merge. Finding the right balance is something each developer will have to learn.

In the end, the merge window remains a bit of an unruly time. The process of channeling the work of several hundred developers into the mainline over a two-week period is unlikely to ever be an entirely smooth experience. But, for all its glitches, the 2.6.27 merge window has been (so far!) easier than 2.6.26. The presence of the linux-next tree almost certainly has something to do with that. This tree's role continues to evolve, but its benefits are starting to be felt.

Comments (1 posted)

Tracing: no shortage of options

By Jonathan Corbet
July 22, 2008

Three weeks ago, LWN looked at the renewed interest in dynamic tracing, with an emphasis on SystemTap. Tracing is a perennial presence on end-user wishlists; it remains a handy tool for companies like Sun Microsystems, which wish to show that their offerings (Solaris, for example) are superior to Linux. It is not surprising that there is a lot of interest in tracing implementations for Linux; the main surprise is that, after all this time, Linux still does not have a top-quality answer to DTrace - though, arguably, Linux had a working tracing mechanism long before DTrace made its appearance.

Even a casual reader of the kernel mailing list will have noticed that there are a lot of tracing-related patches in circulation at the moment. There are so many, in fact, that it is hard to keep track of them all. So this article will take a quick look at the code which has been posted in an attempt to make the various options a bit clearer.

SystemTap

SystemTap remains the presumptive Linux tracing solution of choice. It is hampered by a few problems, though, including usability issues, a complete lack of static trace points in the mainline kernel, and no user-space tracing capability. On the usability side, we are seeing a few more kernel developers trying to put SystemTap to work and posting about the problems they are having. If one takes as a working hypothesis the notion that, if kernel hackers cannot make SystemTap work, many other users are likely to encounter difficulties as well, then one might conclude that addressing the reported problems would be a priority for the SystemTap developers.

The SystemTap developers do seem to be interested in these reports, which is a good sign. There are other things happening in the SystemTap arena, including the release of version 0.7 on July 15. This release adds a number of new features and tapsets, and a substantial set of examples as well. Meanwhile, Anup Shan has posted an interesting integration of SystemTap and the fault injection framework, allowing tapsets to control fault injection and trace the results.

James Bottomley has been playing some with the SystemTap code; one result of that work is changes to SystemTap's internal relocation code in an attempt to make it more acceptable for mainline kernel inclusion. There can be no doubt that the out-of-tree nature of much of the SystemTap support code has made it harder for that code to progress, so any improvement which makes it more likely that some of this code will be merged is welcome.

Also by James is this patch implementing a new way to put markers into the kernel. The addition of markers (or static tracepoints) has always been problematic in that many of these markers, by their nature, need to go into some of the hottest code paths in the kernel. To support dynamic tracing, these markers need to be available on production systems, so they must work without creating any significant performance regressions. Quite a bit of work has gone into the static marker code which is in the kernel (but mostly unused) now, but some developers are still uncomfortable with putting them into performance-critical paths.

James's patch addresses these concerns by putting the tracepoints entirely outside of the code paths. Rather than add some sort of marker to the code, these markers just make a note of just where in the code the marker is supposed to be; this note is stored in a separate part of the kernel binary. That information is enough for a run-time tool to patch in an actual jump to a tracing function should somebody want to see the information from that tracepoint. An additional benefit is that these markers do not interfere with any optimizations done by the compiler. Other solutions can insert optimization barriers which, while they do make life easier for the tracing subsystem, also affect the speed of the code even when the trace points are not active.

Ftrace

The text above said that the kernel's static tracepoint code is "mostly unused." That would have been better expressed as "completely," except that the 2.6.27 kernel will include a user in the form of the ftrace framework. One of the things which makes ftrace truly unique is that its documentation was not only merged before the code itself, but well before: the 2.6.26 kernel includes the excellent Documentation/ftrace.txt file.

The ftrace (which stands for "function tracer") framework is one of the many improvements to come out of the realtime effort. Unlike SystemTap, it does not attempt to be a comprehensive, scriptable facility; ftrace is much more oriented toward simplicity. There is a set of virtual files in a debugfs directory which can be used to enable specific tracers and see the results. The function tracer after which ftrace is named simply outputs each function called in the kernel as it happens. Other tracers look at wakeup latency, events enabling and disabling interrupts and preemption, task switches, etc. As one might expect, the available information is best suited for developers working on improving realtime response in Linux. The ftrace framework makes it easy to add new tracers, though, so chances are good that other types of events will be added as developers think of things they would like to look at.

Tracepoints

The kernel markers mechanism is meant to be the way that static tracepoints are inserted into the kernel. To that end, a great deal of effort went into making these markers fast; they are, for all practical purposes, a set of no-op instructions until somebody wants to turn one on, at which point the real tracing code is patched into the running kernel. Since they were merged, however, kernel markers have been the subject of a few grumbles.

In particular, kernel markers use a somewhat awkward mechanism to ensure that any arguments passed to the tracing function are interpreted correctly there. Each marker has a printk()-style format string associated with it; that string describes the type of each "argument" (a variable or expression within the code being traced). When tracing code activates a marker, it will supply a function to be called when the marker is hit and a format string describing the arguments that the function expects. The marker code will ensure that both format strings match; otherwise the marker will not be enabled. The problem is that the format string requires extra work to write and is only approximate in its specification of the types involved. These strings can make it clear that a given argument is a pointer, for example, but they say nothing about what type is pointed to.

In response to various efforts to get around this issue, Mathieu Desnoyers (the original author of the kernel marker work) has proposed a new mechanism called tracepoints. They are another way of putting static trace points into the kernel, but with a simpler and more type-safe way of putting the pieces together.

With tracepoints, every trace point must be declared in a header file with a mildly ugly set of macros:

    #include <linux/tracepoint.h>

    DEFINE_TRACE(tracepoint_name,
                 TPPROTO(trace_function_prototype),
		 TPARGS(trace_function_args));

This definition will create a new tracepoint called tracepoint_name. Any function attached to that tracepoint must have a function prototype as provided in the TPPROTO() macro; the names of the associated arguments are provided with TPARGS().

Perhaps this is better understood with an example. The tracepoints patch set includes quite a few static points for use with the LTTng tracing toolkit. There is one called sched_wakeup which fires whenever the scheduler wakes up a process. It is defined with:

    DEFINE_TRACE(sched_wakeup,
	         TPPROTO(struct rq *rq, struct task_struct *p),
		 TPARGS(rq, p));

The actual insertion of the tracepoint is a line like this:

    trace_sched_wakeup(rq, p);

Note the trace_ prefix added to the supplied name. At this point in the code, a tracing function can be called with rq (the run queue of interest) and p (the process which is waking up) as parameters. Until an actual function is connected to the tracepoint, though, this declaration is essentially a no-op. Connection of a trace function is done through a call to:

    void my_sched_wakeup_tracer(struct rq *rq, struct task_struct *p);

    register_trace_sched_wakeup(my_sched_wakeup_tracer);

The register_trace_sched_wakeup() function (created as part of the DEFINE_TRACE() definition) will connect the supplied trace function to the tracepoint. The fact that the function prototype for the trace function is supplied as part of the tracepoint definition means that the compiler can perform thorough type checking; if the prototypes do not match up, compilation will fail. And that, in turn, should put an end to those embarrassing situations where turning on tracing causes the system to go down in flames.

Interestingly, tracepoints have dispensed with much of the mechanism developed to minimize the runtime impact of kernel markers; in particular, they do not use the "immediate values" code. Profiling has shown that the performance impact of tracepoints is so low that there is little value in the added complexity of runtime patching of kernel code. Still, there are signs that some kernel developers will object to the addition of tracepoints in their current form. Developers want tracing support - but not at the cost of slower performance, even if that cost is hard to measure.

Tracehook

Finally, Roland McGrath recently surfaced with the tracehook patch set. Tracehook has a rather different focus; it is, essentially, a cleanup of the way the kernel handles the ptrace() system call. The tracehook patches try to organize all of the process tracing code (much of which is architecture-dependent) into one place where it can be dealt with as a unit.

Tracehook is meant to be a first step toward the merging of a new version of the utrace code. Utrace has long been planned as the successor to the current ptrace() implementation, which has few admirers. But utrace has encountered a number of difficulties, so its path into the kernel has been slow. It disappeared from the lists entirely for a while, but a new version of the patches is said to be coming soon; Roland notes that he expects "some vigorous feedback" when that happens.

The real importance of the ptrace() rework is that it is the path toward integrated tracing of kernel- and user-space events. And that, of course, is one of the biggest features offered by DTrace which is not yet available in SystemTap. Getting user-space tracing into the kernel - especially if it could work with the tracepoints already being inserted into some applications for DTrace - would be a major step forward for Linux. A lot of people will be watching when this patch set comes around again.

Meanwhile, Roland would like to see the tracehook code merged for 2.6.27. He is late to the party, though, and this code has not done any time in linux-next. So it is not yet clear whether tracehook will go in before the merge window closes, or whether, instead, it will have to wait for 2.6.28.

In summary...

As can be seen, there is a lot happening in the area of tracing support for Linux. Tracing, it seems, is an idea whose time has come, at last. If the pieces described here can be merged and integrated into a unified framework, and if it can all be made sufficiently easy to use, the time for "DTrace envy" will come to an end. Those "ifs" are not small ones, though. There is quite a bit of work to be done yet; hopefully the current level of energy will remain until the job is done.

Comments (14 posted)

Patches and updates

Kernel trees

Adrian Bunk: Linux 2.6.16.62-rc1. (July 20, 2008)

Adrian Bunk: Linux 2.6.16.62. (July 21, 2008)

Adrian Bunk: Linux 2.6.16.61. (July 18, 2008)

Core kernel code

Arjan van de Ven: fastboot patches series 1. (July 20, 2008)

Ingo Molnar: scheduler updates for v2.6.27, phase #2. (July 21, 2008)

Rusty Russell: module and kmod patches. (July 22, 2008)

David Woodhouse: Imprecise timers.. (July 22, 2008)

David Woodhouse: schedule_timeout_range(). (July 22, 2008)

Development tools

Mathieu Desnoyers: Blktrace port to tracepoints. (July 18, 2008)

Eduard - Gabriel Munteanu: kmemtrace RFC (resubmit 1). (July 20, 2008)

Roland McGrath: tracehook. (July 20, 2008)

Jason Wessel: kgdb 2.6.27 mips. (July 20, 2008)

James Bottomley: fix kallsyms to allow discrimination of local symbols. (July 21, 2008)

Device drivers

Andi Kleen: Please pull ACPI updates. (July 18, 2008)

Marcin Obara: Intel Management Engine Interface. (July 18, 2008)

Michael Buesch: Add SPI over GPIO driver. (July 20, 2008)

Mauro Carvalho Chehab: V4L/DVB updates. (July 20, 2008)

Luis R. Rodriguez: Atheros IEEE 802.11n ath9k driver. (July 21, 2008)

Martin K. Petersen: SCSI Data Integrity Support. (July 21, 2008)

Hannes Reinecke: scsi_dh update. (July 21, 2008)

Greg KH: USB patches for 2.6.26. (July 21, 2008)

Greg KH: driver core patches against 2.6.26. (July 22, 2008)

Bartlomiej Zolnierkiewicz: IDE updates (part 3). (July 23, 2008)

Documentation

Michael Kerrisk: man-pages-3.05 is released. (July 23, 2008)

Filesystems and block I/O

Alasdair G Kergon: device-mapper update for 2.6.27. (July 21, 2008)

J. Bruce Fields: nfsd changes for 2.6.27. (July 21, 2008)

Chris Mason: New data=ordered code pushed out to btrfs-unstable. (July 21, 2008)

Balaji Rao: NFS support for btrfs - v2. (July 21, 2008)

Daniel Phillips: A better solution to the HTree telldir problem. (July 21, 2008)

Daniel Phillips: Tux3, a Versioning Filesystem. (July 23, 2008)

Takashi Sato: freeze feature ver 1.9. (July 22, 2008)

Networking

Krzysztof Halasa: pull request: WAN. (July 20, 2008)

David Miller: : Networking. (July 20, 2008)

David Miller: : Final set of TX multiqueue changes.. (July 20, 2008)

Adam Langley: TCP: Add TCP-AO support. (July 20, 2008)

Architecture-specific

Roland McGrath: x86 step/syscall-trace fixes & cleanups. (July 20, 2008)

Ingo Molnar: x86 updates for v2.6.27, phase #2. (July 21, 2008)

David Miller: : Sparc. (July 21, 2008)

Security-related

Tetsuo Handa: Add a counter in task_struct for skipping permission check. (Was: Should LSM hooks be called by filesystem's requests?). (July 22, 2008)

Virtualization and containers

Nicholas A. Bellinger: - VHACS-VM x86_64 Alpha Preview - FOLLOWUP. (July 20, 2008)

Ranjit Manomohan: Traffic control cgroups subsystem. (July 22, 2008)

Rusty Russell: lguest and virtio patches. (July 23, 2008)

Miscellaneous

Jonathan Corbet: gitdm v0.10 available. (July 20, 2008)

Kay Sievers: udev 125 release. (July 21, 2008)

Hans de Goede: Announcing libv4l 0.3.7. (July 23, 2008)

Page editor: Jonathan Corbet

Distributions

Notes from the Fedora project

By Jonathan Corbet
July 22, 2008

The Fedora folks have a lot of important problems on their mind. As part of that, there is currently a tense election underway - to choose the codename for the Fedora 10 release. There's a list of nine suitably silly, Red-Hat-legal-approved names to choose from. Your editor, fresh from another failed Rawhide update, suggests voting for "terror." Even though Rawhide hasn't been that terrible recently.

Another election - this one for the membership of the Fedora Engineering Steering Committee (FESCO), just finished. FESCO members this time around will be Bill Nottingham, Kevin Fenzi, Dennis Gilmore, Brian Pepple, David Woodhouse, Jarod Wilson, Josh Boyer, Jon Stanley and Karsten Hopp. For the curious, the FESCO mission is:

FESCo handles the process of accepting new features, the acceptance of new packaging sponsors, Special Interest Groups (SIGs) and SIG Oversight, the packaging process, handling and enforcement of maintainer issues and other technical matters related to the distribution and its construction.

The new feature aspect of the job could be interesting in the near future; there has been some clear confusion on what constitutes a new feature, as compared to a mere "enhancement" which does not involve FESCO. The surprising (to some) replacement of RPM in Rawhide was one of those ambiguous issues which brought this question to the fore. There is now an enhanced draft feature policy up for review which, it is hoped, will clarify the situation.

Back in June, the results from the Fedora board election raised some concerns about the process. One reaction to these concerns can now be seen in this proposal for term limits for board members. The reasoning behind this proposal is explained thusly by project leader Paul Frields:

The problem at hand was the perceived dominance by full-time Fedora people on the Board. People who spend their entire $DAYJOB as well as their spare time on Fedora are automatically very involved and visible. That can translate directly to votes on the basis of name recognition, which really disadvantages people who are very involved, but in a somewhat more limited fashion because they don't have the luxury of doing Fedora all day every day.

So the full-time Fedora folks are simply too prominent, to the point that they need to be eased off the stage after a couple of terms on the board to make room for everybody else. Of course, there's a couple of exceptions. The Fedora project leader, not being an elected member of the board, has no such limits. More to the point, though: term limits would not apply to those board members appointed by Red Hat. The reasoning here is:

Extending these term limits to Red Hat appointed seats is not sensible for a number of reasons -- institutional knowledge, flexibility, etc.

As of this writing, there has not been a whole lot of discussion of the term limit proposal; opinions which have been posted are not entirely positive. Fedora project members will want to consider whether this proposal can achieve its stated goal. It would be unfortunate if an up-and-coming outsider - with associated institutional memory - got term-limited off the board just as they were really hitting their stride.

Finally, OLPC enthusiasts may want to have a look at the newly-formed OLPC special interest group. This group is working to make the Fedora distribution (already shipped by OLPC) as well suited to that platform as possible. One of the results should include a special Sugar "spin" of Fedora. There is a mailing list available for interested people to join.

Comments (4 posted)

New Releases

BLAG 90001 (oxygen) Released

BLAG 90001 is out; it is mainly an update for various "annoying issues" in BLAG 90000. "In sum, this release contains less suck." It has 97 package updates in all.

LWN.net Weekly Edition for July 24, 2008

afuse: privilege escalation

bacula: password disclosure

bitchx: boundary error and temporary file vulnerability

kernel: null pointer problems

kernel: privilege escalation

libxcrypt: incorrect hash algorithm used

mantis: multiple vulnerabilities

ruby: integer overflows

SystemTap

Ftrace

Tracepoints

Tracehook

In summary...

Events: July 31, 2008 to September 29, 2008