LWN.net Weekly Edition for January 31, 2008 [LWN.net]

Ten-year timeline part 4: the end and the beginning

By Jonathan Corbet
January 30, 2008

When your editor started this series, the idea was to have four installments covering the ten-year life (so far) of LWN. Well, this is the fourth installment, and it gets less than halfway there. This is not, it seems, a topic which inspires brevity. So this series will continue past the anniversary, though your editor anticipates picking up the pace a bit for the second five years. There is less to be learned, arguably, by looking at events in the relatively recent past.

Anyway, at the end of the third installment, LWN had been unacquired by Tucows and was, once again, on its own. The worst of the dotcom bust may have passed, but it was still a somewhat scary environment in which to be attempting to restart a business. It was, in fact, even scarier than we had thought when we so naively set out to show that we could do a better job of bringing in the cash than Tucows did.

February 7, 2002: Linus tries BitKeeper at last.
February 14, 2002: Sun states that it will "ship a full implementation of the Linux operating system." Dave Whitinger joins LWN.net.

Dave Whitinger was, of course, one of the founders of LinuxToday. He joined LWN with the intent of helping us develop the advertising side of the business. That did not work out as intended, but it is hardly Dave's fault; it was a terrible time to be trying to sell advertising.

February 28, 2002: Sun cuts off free access to StarOffice, but we had OpenOffice.org by then and didn't mind. BitKeeper starts to settle in as the kernel's source management system.

Linus stuck with BitKeeper after his initial trial, setting a number of things in motion. For the next few years, the use of proprietary software at the core of the kernel development process would be a constant source of unhappiness and worry - and, in fact, the story had just the sort of unhappy ending that some observers had feared. But this was also the move which rationalized the kernel work flow and made the whole system scale; the incredible rate of change we see now would not have been possible without it. The use of BitKeeper also made the community aware of what distributed source control could do and, eventually, inspired the creation of a number of free programs with the same essential features. One could say that the community would have eventually developed these systems on its own without the push from Larry McVoy and BitKeeper, and that's probably true. But the fact is: we didn't do it at that time, so we had no real alternative to BitKeeper.

March 7, 2002: Martin Dalecki's "IDE cleanup" patches start to raise concerns among kernel developers, who have this strange notion that their disks should actually work. A petition against the use of BitKeeper circulates on the net. Eric Raymond goes around telling the world that the kernel development process is "in crisis."
March 14, 2002: Richard Stallman claims that the GNU HURD will be ready by the end of the year. MandrakeSoft pleads for donations to keep the business alive - and LWN does too. Martin Dalecki officially takes over IDE maintenance - and breaks more systems.

We got about $5,000 from our initial plea for donations. It was a real act of generosity on the part of our readers, but one does not keep a business with five employees going for very long with that sort of money.

March 28, 2002: The proposed "consumer broadband and digital television promotion act" would require DRM technology in all software which touches digital media. Lineo lays off more staff.
April 25, 2002: More BitKeeper flames. Lineo goes through a "recapitalization" effort to be able to do things like pay its employees.
May 2, 2002: OpenOffice.org 1.0 is released.
June 6, 2002: LWN switches to the "new" site code. Red Hat applies for a few software patents. ADEOS, a real-time system which avoids the RTLinux patent, is released. UnitedLinux launches. Mozilla 1.0 is released.

It is amazing how many readers hated the new code. Certainly there were a lot of silly things in the initial version of the site; we fixed a number of them in a hurry. Many readers disliked the ability to post comments - often posting comments to that effect. The addition of comments was something we thought about carefully for a long time; we were quite concerned that they could ruin the feel of the site. In the end, it seems, trusting our readers has paid off; the quality of the conversation here is often quite good.

UnitedLinux was a cooperative effort between Caldera, Conectiva, SuSE, and Turbolinux; the idea was to join together to create a common base from which each could then craft a separate product. The effort was never all that successful, and the presence of Caldera would, of course, doom it outright in the end. But it was a big deal at the time. It is interesting to see that Mandriva (despite MandrakeSoft's refusal to join UnitedLinux) and Turbolinux are now attempting a very similar sort of arrangement.

June 13, 2002: Secure Computing Corporation claims patents on SELinux.
June 27, 2002: The 2002 kernel summit sets October 31 as the date for the 2.6 feature freeze. GNOME 2.0 is released.
July 4, 2002: Darl McBride takes over at SCO.
July 25, 2002: LWN announces "the end of the road." The "IDE cleanup" patch series (up to number 100) causes system lockups and file corruption. Debian GNU/Linux 3.0 ("woody") is released. Version 1.0 of the Ogg Vorbis codec is released.

By the end of July, we had come to realize that the advertising business was not going to work out for LWN, and we were short of other ideas. The bank account had reached a point where we could not pay even very small expenses. So we concluded that it was time to throw in the towel and try something else - though we had no clue of what "something else" might be. It was with a heavy heart that we announced our plan to shut down the site.

What happened next is that our donation box, which had sat mostly empty after the initial announcement, was suddenly topped up to the tune of about $35,000. Many of the donations came with notes to the effect of "use this to throw a big party." This, shall we say, got our attention. We decided that, just maybe, the subscription idea was worth a try after all, and decided to make a go of it. It was not the end after all.

August 1, 2002: A new beginning. HP tries to use the DMCA to shut down disclosure of security holes.
August 15, 2002: Distributions from MandrakeSoft, Red Hat, and SuSE are certified to be compliant with the Linux Standard Base.

This was when our credit card merchant bank at the time decided that all those donations might just be fraudulent. So they seized the money back out of our bank account. That, too, got our attention. It took a few months and some lawyer time to get the money you all had sent in our direction; during that time, it was money from PayPal (the subject of everybody else's horror stories) that kept the lights on while our main source of cash was blocked.

Needless to say, we got a new merchant bank, which we still use to this day. The new bank exhibits a rather higher clue level than the old one did, but we also learned a valuable lesson: don't mess with the credit card money pipeline. Every now and then, somebody asks why we don't accept pure donations; this is why.

August 22, 2002: Martin Dalecki quits and the entire series of 115 "IDE cleanup" patches is deleted from the 2.5 kernel.
August 29, 2002: British Telecom's attempt to patent the web dies in court. The BitKeeper license changes. Caldera becomes the SCO Group.
September 12, 2002: Some patches get dropped after Linus starts running his mail through a spam filter.

It's hard to believe that, only 5+ years ago, somebody with an email address as well distributed as Linus's could get by without spam filtering. There are a lot of free "productivity" applications, but, arguably, few have actually increased productivity to the extent that SpamAssassin has.

September 26, 2002: The first development release of the "Phoenix" browser is announced. UnitedLinux upsets the community by releasing a closed beta.

Phoenix was the Mozilla Foundation's answer to (relatively) lightweight browsers like Galeon, which had managed to turn the Gecko engine into something which was truly usable. The Phoenix browser proved popular, and eventually became the tool now known as Firefox.

October 3, 2002: The first subscriber-only weekly edition. Eldred v. Ashcroft is argued in the U.S. Supreme Court.

Eldred v. Ashcroft, argued by Lawrence Lessig, was an attempt to roll back copyright extension in the US; it eventually was unsuccessful. To this day, there still has not really been a successful challenge to the extensions to copyright passed over the last few decades - though some especially nasty attempts to make things even worse were defeated.

With the October 3, 2002 edition, LWN adopted the new policy of requiring subscriptions in order to read our original content prior to the publication of the weekly edition. That policy has stayed essentially unchanged since then, despite the occasional temptation to increase the subscriber-only period. Subscription rates have also stayed unchanged, even though raising them is also tempting.

Subscriptions have certainly been successful, in that they have kept the operation going in the years since then. And there is a real joy associated with being truly answerable to our readers instead of advertisers. Nonetheless, it is a challenging business; people do not like to pay to read web-based content. The fact that so many of our readers are willing to do so is most gratifying. Trends in other parts of the net are moving away from this approach, though, with formerly subscription sites moving to pure advertising models. So it will be interesting to see how it all plays out in the future.

Meanwhile, next week's installment will look at how things went for Linux (and LWN) starting toward the end of 2002. Stay tuned.

Comments (39 posted)

LCA: Bruce Schneier on the two sides of security

By Jonathan Corbet
January 30, 2008

The conference portion of linux.conf.au opened on Wednesday morning with a keynote by Bruce Schneier. LCA is a sold-out event; in fact, there are rather more attendees than can be fit into the hall where the keynotes are held. Thus the room was packed, with the second-class citizens - those with yellow badges who put off registration until late - watching a remote feed in a separate room. Those folks may have had a more distant experience, but it was almost certainly a cooler one too.

Bruce's key point is that we need to rethink how we try to achieve security, though it took a while to explain just why that is. Security, he says, has two components:

The feeling of security: that which helps us to sleep well at night.
The reality of security: whether we are, in fact, secure.

These two aspects of the problem are entirely separate from each other, but they both have to be addressed if our security goals are to be achieved.

Security is always a set of tradeoffs which we are all making every day. As an example, consider that, in all likelihood, nobody in the audience was wearing a bulletproof vest. It's not that the vests do not work; instead, nobody feels that the cost of wearing a bulletproof vest is justified given the risk. On a bigger scale, the answer to the question of how to prevent more 9/11-like attacks is clear: ban all aircraft. In fact, that was done in the US for a few days after those attacks, but, in the longer term, that is not a tradeoff that people are willing to make.

So the fundamental question for any security tradeoff is: is it worth it? As it happens, we are quite bad at making that decision. We tend to respond to feelings rather than reality. Spectacular risks drive us more than everyday risks. We fear the strange over the familiar and the personified (think Osama bin Laden) over the anonymous. Involuntary risks are seen as being bigger than those entered into voluntarily. In the end, evolution has equipped us quite well for making tradeoffs in the small communities we lived in many, many thousands of years ago. We are less well equipped for the world we live in now.

Since we respond to feelings more than reality, there are strong economic incentives for solutions which address feelings. The result is snake-oil products and security theater. Sometimes people notice that they are being sold bad security (later Bruce mentioned a US survey which indicated that the Transportation Security Agency is now less trusted than the taxation agency), but, all too often, they don't. They have a poor understanding of the risks and the costs involved, and there are plenty of people with strong interests in confusing the issue.

The security market is a lemons market, one where buyers and sellers have asymmetric access to information. Economic research shows that, in such markets, the bad products tend to drive the good ones out of the market. There is no easy way to evaluate the work which has gone into the creation of a truly secure product, so buyers respond to other, less reliable signals. Things like price, sales claims, or the Gartner Group. These signals are sloppy and prone to manipulation. When security is outsourced to outside agencies - governments, say - the problem gets even worse.

In the business world, information eventually brings some order to a lemons market. As businesses learn about what really works, access to information evens out - though there is always a problem with very rare, high-cost events where information is not available. In the individual world, though, it is much harder, because fear plays a much bigger role.

The fact of the matter is that fear is wired deeply into how we work - it is a result of a very old part of our brain. As humans, we have the ability to override our fears when reason indicates that we should, but it is a hard thing to do. The default state is that fear rules. So this is Bruce's core point: the feelings matter. All that security theater out there is not entirely stupid; any security solution must address the fears that people feel. We must address both aspects of security.

The problem is where the feeling of security and the reality of security diverge from each other. If only feelings are addressed, security has not really been achieved. If only the reality of security is addressed, people feel insecure and may make bad decisions. Either way, the full problem has not been solved. Addressing this all-too-common problem is hard, though; Bruce knows of no better way than the spreading of good information.

Your editor's perspective follows - nothing from this point on was said during the talk. It seems that he has a point here. Consider some common situations in the free software world:

A large number of security updates from a distributor may be an indication that the reality of security is being achieved: problems are being found and fixed before they are exploited. But all those updates can undermine the feeling of security. The seemingly endless stream of Wireshark updates is a case in point; most of these problems are found through proactive auditing by the developers and have never been exploited by the Bad Guys. But the feeling of insecurity associated with Wireshark can be strong. This feeling can push users toward other software which, while not having that long history of security updates, is actually less secure.
A system running SELinux may, in fact, be highly secure. But many administrators still turn it off. SELinux does not make them feel secure because they do not understand it, and they fear (rightly or wrongly) that it will interfere with the proper operation of the system. But, by turning it off, they undoubtedly expose themselves to a number of attacks which SELinux would block.

We should hear Bruce's point and think a bit more about how we can ensure that free software creates the feeling of security - but a feeling which is backed up by real security. It's a hard problem, one which lacks technical solutions. But we'll find ourselves less secure than we would otherwise be if we do not address that side of the issue.

Comments (17 posted)

A ten-year retrospective from LWN's other co-founder

January 28, 2008

This article was contributed by Elizabeth O. Coolbaugh

Hello to all LWN readers! For the tenth anniversary of LWN, I've been dragged out of my closet to say a few words. Am I stunned that LWN is still going after 10 years? Not really. Much more stunning to me is the realization that the number of years LWN has been published without me are now almost double the number of years it was published with me. That is much harder to get over. As a result, all new readers from 2002 on have no reason to know who I am or what I've written in the past. For those of you that remember me and have asked about me, thank you and rest assured that I haven't forgotten you either.

My name is Elizabeth Coolbaugh (Liz) and I was there for the very first issue as well as many issues that followed in 1998 through 2001. I've always said it was the very best job I ever had. I wish for all of you, if you haven't experienced it yet, a job where your first weeks of work are greeted with happy, enthusiastic letters. As the years went by, letters of praise, though much sparser, never totally ceased. You couldn't have a better incentive to work harder and harder!

Jon has done an excellent job of going over the history of the first few years already, so all I can add is some tidbits or personal viewpoints. I'll mention that for me, the start of LWN was actually back in the early 1980's, when Jon, Becky and I came together as a programming team in the then infamous "Assembly Language Programming" class offered through the Engineering School at CU Boulder. We got a chance to experience lots of late nights, interesting hardware experiences and how to keep going with pizza, chocolate, caffeine, etc. That is a good way to get to know your future business partners. Jon and Becky never let me down and we all found different strengths to add to the mix. Forrest was around, too, though not working with us directly at the time.

Jon mentioned that I was between jobs at the time we began. In fact, I had left NCAR three months pregnant. I loved working at NCAR for many, many years, but I had always said that I would leave it when the work stopped being fun. It actually stopped being fun about two years before that, but I had weathered rough times before and waited to make sure the situation wasn't going to turn-around before choosing to move on. The challenge of a new baby on the way (and the continuing challenge of the Multiple Sclerosis that eventually led to my departure from LWN) finally made it "the right time".

So I'd actually had most of a year off to recuperate, re-organize, have a baby and test the job market waters. What I wanted was a job that used my professional skills and yet was part-time, to help me keep the health I'd regained. What a pipe-dream! Companies that would have gladly recruited me full-time just tossed my resume into the nearest recycle bin. The nicer ones told me to go out and find someone else with identical skills who wanted to job-share a full-time job and they would be willing to consider the possibility. Not bloody likely.

So when Jon and I were having lunch and he suggested we might be able to work together to create something giving me what I wanted and allowing him to eventually leave NCAR, it seemed to be the right idea at the right time. I never regretted the decision, but in fact, I had a full-time working spouse to cushion the decision. Brandon's reaction (my husband) to becoming the sole support of the family and a new father in one fell swoop was a little different -- much like a deer full-blinded by headlights.

In the spirit of true confessions, though I had fifteen years experience in the computing field and had worked with many different operating systems, VMS and Solaris being primary, I'd never actually touched a Linux system. Jon's unwavering belief in my ability to pick it all up in a heartbeat was both daunting and encouraging at the same time. So I installed my first Linux system only three or four months before we first started publishing. It did give me a fresh, unbiased view of the whole community, though. Okay, not totally unbiased. I did sit on the emacs side of the whole emacs/vi war.

To get started, I subscribed to say, a hundred different newsgroups and mailing lists full of people I'd never met, topics I'd never heard of and flame wars I didn't care to read. It was truly a new skill to develop to learn to skim through them searching for the topics people cared about, the posts that actually carried real information and gently lift each little kernel of "news" out and place in into the newsletter, then wait to hear how well I'd done.

The response was totally overwhelming. I will never, ever forget the emails we received those first couple of months. New people were finding us each week and so the responses kept coming in. They drove me to try and make my contributions worthy of the praise they sent. It is because of those emails that I'm not surprised LWN is still out there today. People wanted and needed what we had to offer. Jon's vision of what people liked and wanted has always been clear and that is another important piece of why LWN is still going strong.

My take on the Red Hat Support fiasco: I have no hard feelings. Although my work as a systems administrator had always included supporting people and I had enjoyed the interaction, I had no idea what I was getting into offering 24 hour support from my home. Just as my daughter was getting old enough to give me a full-night's sleep, I was getting phone calls at 2am and 3am, having to wake up to a fully alert state and go into emergency fix-it mode. I'm surprised I survived until all the contracts we had sold finally expired. In the long run, Red Hat's ideas gave us the courage to start our own business and since writing for LWN was what I learned to love, I consider the end result to have worked out for the best. I also carefully noted for the future that telephone support work was definite going to be a last resort for any future career moves.

Meanwhile, since the few contracts we had didn't bring in enough to pay the bills, let alone enough to support Jon's full-time entry, I also did contract work as a technical writer, remote or on-site administration of Linux for some local companies and I don't even remember what else. Eventually, Jon had to take the risk, forgo waiting for a reliable income and quit his day job in order to increase the income stream. Note that his early work on LWN was always done in addition to continuing his full-time job and trying to increase our income stream at the same time. No wonder he got grumpy if I was out sick or worse, got to head to a fun Linux conference, leaving him to pick up the slack! Of course, it was terrifying in turn for me when the situation reversed and Jon was unavailable. Picking up the kernel page for the week? Ack! I didn't usually complain. Instead, I kept my head low, worked hard and hoped not to see too many corrections or criticisms come in.

It was wonderful for both Jon and I when we were finally able to add Becky to the mix. I think initially we were only able to scrape up enough to pay her for 10 hours a week, but every hour helped. I haven't forgotten, Becky (okay, it should be Rebecca, but she'll always be Becky to me), the hours you put in at a very low rate of pay. Of course, we did pay you first -- the downside to being the business owners for us.

Over the course of the next couple of years, we continued to bring in our income from other sources. We did actually initiate putting some advertising on our site and it brought in a tiny amount of money, but the bread and butter of the company continued to be contract work done in addition to the weekly publication. That included our most successful side foray, building and teaching Linux classes.

What else did I love about LWN? I so enjoyed the friendships I made throughout so many different communities. Will Rogers once said he never met a man he didn't like. Well, I've met many! But truly, in all the years I worked for LWN, I never met anyone I didn't like. Sometimes people I liked said things or did things that I didn't like, but underneath it, they were all good people, smart, idealistic and very strongly opinionated. That was part of what I liked and enjoyed, so I never held people's opinions against them.

The conferences I attended and at which I spoke were like the icing on the cake. I got to meet in-person people I had only come to know through newsgroups and mailing lists or occasionally personal correspondence. I got to meet even more people and share in the excitement. And yes, I do remember the late nights going out for food, drink and conversation with you -- the Atlanta Showcase, LinuxWorld San Jose, Embedded Systems Conference San Jose, LinuxWorld New York, the Colorado Linux Info Quest and the Singapore Linux Conference. Each one provides me with rich memories. My trip out to Singapore was one high-point. So many good and wonderful people and such a wonderful experience. I thought it was to be the first of many international conferences that I would be attending and I am still so sad that it was my last. I particularly regret never making it out to any of early Linux conferences in India, despite invitations.

Professionally, though, the highlight of the work was actually developing myself as a journalist, rather than a computer expert. I enjoyed researching more in-depth articles. When rumors floated my way, I loved actually going out and contacting the people involved first hand by telephone -- short-circuiting email and the rest, to discuss the issues and get their first-hand viewpoints. Since our community wasn't exactly hounded by the media back then, everybody actually wanted to talk to me and was more than happy to give me the straight scoop, instead of just seeing themselves misquoted elsewhere the next day, with the resultant flames. Best of all, I was occasionally able to get the sources of both sides of a controversy together and talk. I can think of at least twice where problems got resolved as a result, people got together and I got the scoop on a story the next day that had literally changed as a result of my work. Very heady stuff.

Jon has already done an excellent job of covering our experience with the dot-com bubble, so I won't add to his description. It was truly a unique life experience that we enjoyed to the fullest, knowing that another like it was unlikely to come by us again. We were very fortunate in our decisions and I agree that the people at Tucows were extremely good to us.

Well, at this point, all this happened a long time ago. I had a great time and regret nothing I did, only the things I didn't get time to do. For those who have asked after me personally, be assured that health-wise, giving up my job was again the right choice at the right time and I'm doing much, much better than I was in August of 2001. You're still not likely to see me back any time in the near future. I focus my research skills now-a-days on tracking traditional and alternative medical discoveries, implementing what seems good to me and serving as an ad-hoc resource for other family members. Oh yes, and serving as a chauffeur to my daughter, who is now ten years old, just as LWN is. Take care, all of you, remember to be proud of what you are achieving and *always* have fun doing it. I stand by my opinion that when work ceases to be fun, it is time for a change.

Comments (12 posted)

Finding bugs lurking in the DOM

By Jake Edge
January 30, 2008

The Document Object Model (DOM) for HTML is quite useful for handling a variety of dynamic effects for web pages, but it is complex. It interacts with Javascript and CSS (or they with it) in ways that are sometimes surprising—the DOM has often been the source of browser bugs. A new project, from well-known DOM bug finder Michal Zalewski, seeks to systematically exercise the DOM in browsers to eliminate as many holes as it can.

The project, with the unassuming name of DOM access checker (or dom-checker) was just announced on the full-disclosure mailing list (along with Bugtraq and others). Zalewski and colleague Filipe Almeida, both of Google, describe their tool as follows:

DOM access checker is a tool designed to automatically validate numerous aspects of domain security policy enforcement (cross-domain DOM access, Javascript cookies, XMLHttpRequest calls, event and transition handling) to detect common security attack or information disclosure vectors.

The checker consists of a three HTML files and a Javascript configuration file that can be loaded from the internet via HTTP (a live version is available from the project website) or from the local disk, using the file:// protocol. Ideally, they should be loaded from both places and give the same results. The screenshot for a sample run using Firefox 3 (Fedora/3.0b3pre-0.beta2.12.nightly20080121.fc9 for the curious) is at left.

After pressing the "Click here to begin tests" button, the Javascript test harness runs 15 major tests, each with many separate subtests. Each subtest reports success or failure to the screen as it runs. Firefox 3 failed 15 of the 1500 or so checks in the standard set of tests.

According to the announcement, "DOM Checker had been used to find a number of major security bypass and information disclosure problems in several popular browsers". Zalewski and Almeida worked with the browser teams to resolve the most serious issues. But, common browsers will still fail up to 30 of the less important tests—for privacy, rather than security, holes.

The hope is that the browser vendors pick up these tests to use as part of their quality assurance process. They could also be used for regression testing to find problems that have crept in while fixing other bugs or adding new features. The checker is a framework that could easily be extended with additional tests covering other areas of DOM functionality. With the advent of AJAX, DOM manipulations via Javascript are being used more and more by web sites, so tools to discover these kinds of bugs are welcome.

Comments (5 posted)

gforge: cross-site scripting

Package(s):

gforge

CVE #(s):

CVE-2007-0176

Created:

January 28, 2008

Updated:

January 30, 2008

Description:

From the NVD entry:

Cross-site scripting (XSS) vulnerability in search/advanced_search.php in GForge 4.5.11 allows remote attackers to inject arbitrary web script or HTML via the words parameter.

Alerts:

Debian

DSA-1475-1

gforge

2008-01-26

Comments (none posted)

icu: arbitrary code execution

Package(s):

icu

CVE #(s):

CVE-2007-4770 CVE-2007-4771

Created:

January 25, 2008

Updated:

May 15, 2008

Description:

From the Red Hat advisory: Will Drewry reported multiple flaws in the way libicu processed certain malformed regular expressions. If an application linked against ICU, such as OpenOffice.org, processed a carefully crafted regular expression, it may be possible to execute arbitrary code as the user running the application.

Alerts:

Gentoo	200805-16	openoffice	2008-05-14
SuSE	SUSE-SA:2008:023	OpenOffice_org	2008-04-18
Ubuntu	USN-591-1	icu	2008-03-24
Debian	DSA-1511-1	libicu	2008-03-03
Gentoo	200803-20	icu	2008-03-11
SuSE	SUSE-SR:2008:005	acroread, asterisk, cacti, compat-openssl097g, icu, libcdio, wireshark/ethereal, Jakarta, perl-tk	2008-03-06
rPath	rPSA-2008-0043-1	icu	2008-02-06
Mandriva	MDVSA-2008:026	icu	2008-01-25
Fedora	FEDORA-2008-1036	icu	2008-01-27
Fedora	FEDORA-2008-1076	icu	2008-01-27
Red Hat	RHSA-2008:0090-01	icu	2008-01-25

Comments (none posted)

kernel: several vulnerabilities

Package(s):

linux-2.6

CVE #(s):

CVE-2007-2878 CVE-2007-6151

Created:

January 29, 2008

Updated:

January 8, 2009

Description:

From the Debian advisory: Bart Oldeman reported a denial of service (DoS) issue in the VFAT filesystem that allows local users to corrupt a kernel structure resulting in a system crash. This is only an issue for systems which make use of the VFAT compat ioctl interface, such as systems running an 'amd64' flavor kernel. ADLAB discovered a possible memory overrun in the ISDN subsystem that may permit a local user to overwrite kernel memory leading by issuing ioctls with unterminated data.

Alerts:

Red Hat	RHSA-2008:0787-01	kernel	2009-01-05
Red Hat	RHSA-2009:0001-01	kernel	2009-01-08
SuSE	SUSE-SA:2008:032	kernel	2008-07-07
Mandriva	MDVSA-2008:112	kernel	2007-06-12
CentOS	CESA-2008:0211	kernel	2008-05-07
Red Hat	RHSA-2008:0211-01	kernel	2008-05-07
Mandriva	MDVSA-2008:086	kernel	2008-04-15
SuSE	SUSE-SA:2008:017	kernel	2008-03-28
Debian	DSA-1504	kernel-source-2.6.8	2008-02-22
Debian	DSA-1503	kernel-source-2.4.27	2008-02-22
Debian	DSA-1503-2	kernel-source-2.4.27	2008-03-06
Ubuntu	USN-578-1	linux-source-2.6.15	2008-02-14
SuSE	SUSE-SA:2008:007	kernel	2008-02-12
Ubuntu	USN-574-1	linux-source-2.6.17/20/22	2008-02-04
Red Hat	RHSA-2008:0055-01	kernel	2008-01-31
Debian	DSA-1479	linux-2.6	2008-01-29

Comments (none posted)

mysql: buffer overflows

Package(s):

mysql-dfsg-5.0

CVE #(s):

CVE-2008-0226 CVE-2008-0227

Created:

January 29, 2008

Updated:

July 21, 2008

Description:

From the Debian advisory: Luigi Auriemma discovered two buffer overflows in YaSSL, an SSL implementation included in the MySQL database package, which could lead to denial of service and possibly the execution of arbitrary code.

Alerts:

Mandriva	MDVSA-2008:150	mysql	2007-07-19
Ubuntu	USN-588-2	USN-588-1 fixed	2008-04-02
Ubuntu	USN-588-1	mysql-dfsg-5.0	2008-03-19
rPath	rPSA-2008-0040-1	mysql	2008-02-05
Debian	DSA-1478-1	mysql-dfsg-5.0	2008-01-28

Comments (none posted)

netkit-ftpd: denial of service

Package(s):

netkit-ftpd

CVE #(s):

CVE-2007-6263

Created:

January 30, 2008

Updated:

January 30, 2008

Description:

From the Gentoo advisory:

A remote attacker can send specially crafted FTP data to a server with passive mode and SSL support, causing the ftpd daemon to crash.

Alerts:

Gentoo

200801-17

netkit-ftpd

2008-01-29

Comments (none posted)

ngircd: denial of service

Package(s):

ngircd

CVE #(s):

CVE-2008-0285

Created:

January 28, 2008

Updated:

January 30, 2008

Description:

From the NVD entry:

ngIRCd 0.10.x before 0.10.4 and 0.11.0 before 0.11.0-pre2 allows remote attackers to cause a denial of service (crash) via crafted IRC PART message, which triggers an invalid dereference.

Alerts:

Gentoo

200801-13:02

ngircd

2008-01-27

Comments (none posted)

pulseaudio: ignores setuid() return value

Package(s):

pulseaudio

CVE #(s):

CVE-2008-0008

Created:

January 25, 2008

Updated:

February 14, 2008

Description:

Pulseaudio ignores setuid() return value. A user can cause the call to fail by exhausting the resources in some cases.

Alerts:

Gentoo	200802-07	pulseaudio	2008-02-13
Ubuntu	USN-573-1	pulseaudio	2008-01-31
Mandriva	MDVSA-2008:027	pulseaudio	2007-01-25
Debian	DSA-1476-1	pulseaudio	2008-01-27
Fedora	FEDORA-2008-0994	pulseaudio	2008-01-24
Fedora	FEDORA-2008-0963	pulseaudio	2008-01-24

Comments (none posted)

tikiwiki: multiple vulnerabilities

Package(s):

tikiwiki

CVE #(s):

CVE-2007-6528 CVE-2007-6526 CVE-2007-6529

Created:

January 24, 2008

Updated:

January 30, 2008

Description:

From the Gentoo alert:

Jesus Olmos Gonzalez from isecauditors reported insufficient sanitization of the "movies" parameter in file tiki-listmovies.php (CVE-2007-6528).

Mesut Timur from H-Labs discovered that the input passed to the "area_name" parameter in file tiki-special_chars.php is not properly sanitised before being returned to the user (CVE-2007-6526).

redflo reported multiple unspecified vulnerabilities in files tiki-edit_css.php, tiki-list_games.php, and tiki-g-admin_shared_source.php (CVE-2007-6529).

Alerts:

Gentoo

200801-10

tikiwiki

2008-01-23

Comments (none posted)

yarssr: arbitrary code execution

Package(s):

yarssr

CVE #(s):

CVE-2007-5837

Created:

January 28, 2008

Updated:

January 30, 2008

Description:

From the NVD entry:

GUI.pm in yarssr 0.2.2, when Gnome default URL handling is disabled, allows remote attackers to execute arbitrary commands via shell metacharacters in a link element in a feed.

Alerts:

Debian

DSA-1477-1

yarssr

2008-01-27

Comments (none posted)

Kernel release status

The current stable 2.6 kernel is 2.6.24, released by Linus on January 24. Highlights of this release include control groups (formerly process containers), the i386/x86_64 architecture merger, group scheduling in the CFS scheduler, network and PID namespaces, kernel markers, the removal of the modular security interface, and much more. See LWN's list of merged patches for more detail, or the always-amazing KernelNewbies Linux Changes page for much more detail.

The 2.6.25 merge window is open, but the process of picking up patches is going relatively slowly due to the distractions of linux.conf.au. See the article below for a summary of what has been merged to date.

For older kernels: 2.6.16.60 was released on January 27 with about a dozen fixes.

Comments (none posted)

Quotes of the week

I skipped a lot of these patches because I just got bored of fixing rejects. Now is a very optimistic time to be raising patches against mainline.

I'm going to work on getting a unified devel tree operating: one which contains everyone's latest stuff and is updated daily. Basically it'll be -mm without a couple of the quilt trees. People can then prepare patches against that, as it seems that most can't be bothered patching against -mm, let alone building and testing it. More later.

-- Andrew Morton

Even Anton Blanchard's phone calls have a signed-off-by line.

-- AntonBlanchardFacts.com

Comments (none posted)

What got into 2.6.25

By Jonathan Corbet
January 30, 2008

As of this writing, some 3800 patches have been merged into the mainline git repository since the release of 2.6.24. That is fewer than one might have expected, but Linus's travel to linux.conf.au is slowing the process somewhat. Expect more than the usual amount of interesting stuff to be merged relatively late in the merge window period.

User-visible changes include:

New drivers have been added for Globe Trotter HSDPA wireless cards, HIFN 795x crypto accelerator chips, Xceive xc2028 and xc5000 tuners, Cirrus Logic CS5345 analog-to-digital converters, several Beholder TV tuners, Syntek DC1125 cameras, Silicon Labs Si470x FM radio receivers, Atmel AT91CAP9 processors, Qualcomm MSM7X00A processors, Marvell Orion system-on-a-chip devices, Marvell Feroceon processors, SuperH 7203 and 7263 processors, SGI IP28 systems, R6040 Ethernet adapters, Broadcom NetXtremeII 10Gb network adapters, RTL8180 and 8185-based wireless network cards, Microchip EN28J60 Ethernet chips, and, finally, Atheros-based wireless network adapters.
The Seagate ST-02/Future Domain TMC-8xx and PSI240i SCSI drivers have been removed due to lack of interest and maintenance.
Salsa20 stream cipher support has been added to the crypto layer (at least for the x86 architecture - it's an assembly implementation).
Some realtime work has gone into the scheduler; in particular, the kernel will be more aggressive about moving tasks between processors when multiple realtime tasks are contending for the same CPU. The implementation of cpusets has been made to work more with the scheduler domains mechanism. The option to make the big kernel lock preemptible has been made the default; eventually the non-preemptible version will go away altogether. High-resolution timers can be used for preemption, making fair scheduling more accurate. The group scheduling feature has been enhanced with realtime support.
The Preemptible read-copy-update patches have been merged.
Support for the LatencyTop utility has been merged.
Kprobes support for the ARM architecture has been added.
The new CLONE_IO flag to clone() causes I/O contexts (used in the CFQ block I/O scheduler) to be shared with the new child process.
The idle class for I/O scheduling has been changed to not be 100% idle when the device is busy; as a result, it is far less likely to cause priority inversion problems and is no longer limited to privileged processes.
A long list of new ext4 features, including large file support, (very) large filesystem support, journal checksumming, multi-block allocation, and more, has been added in.
The splice() system call now supports TCP receive streams.
Controller area network protocol support has been merged.
The network traffic shaper, long obsolete and scheduled for removal, is gone.
Quite a bit of work has been done on the network namespace code which was first merged in 2.6.24. Extending namespace awareness through the entire networking subsystem is a big job which is, at this point, mostly complete.

Changes visible to kernel developers include:

Chinese translations of a number of core kernel development documents have been added to the tree.
There have been a great many changes to the low-level device model APIs dealing with kobjects and ksets. These changes have, in turn, forced a large number of adjustments throughout the tree. See Documentation/kobject.txt for an overview of the new API.
There is a new set of security module functions for dealing with filesystem mount and unmount operations.
The chained scatterlist API has been augmented with the sg_table patches.
There have been some changes to the block request completion API. See this article for a description of the new way of doing things.

As of this writing, the merging process has just begun, so expect a long list again next week. Among other things, the x86 tree update, with 908 changesets, is waiting on the wings. There is quite a bit of code yet to be merged for this development cycle.

Comments (2 posted)

Avoiding the OOM killer with mem_notify

By Jake Edge
January 30, 2008

Having applications that use up all the available memory can be a fairly painful experience. For Linux systems, it generally means a visit from the out-of-memory (OOM) killer, which will try to find processes to kill. As one would guess, coming up with rules governing which process to kill is challenging—someone, somewhere, will always be unhappy with a choice the OOM killer makes. Avoiding it altogether is the goal of the mem_notify patch.

When memory gets tight, it is quite possible that applications have memory allocated—often caches for better performance—that they could free. After all, it is generally better to lose some performance than to face the consequences of being chosen by the OOM killer. But, currently, there is no way for a process to know that the kernel is feeling memory pressure. The patch provides a way for interested programs to monitor the /dev/mem_notify file to be notified if memory starts to run low.

/dev/mem_notify is a character device that signals memory pressure by becoming readable. Interested programs can open the file and then use poll() or select() to monitor the file descriptor. Alternatively, signal-driven I/O can be enabled via the FASYNC flag and the system will deliver a SIGIO signal to the process when the device becomes readable. If it becomes readable, the process should free any memory that it can afford to give up. If enough memory is freed this way, the kernel will have no need to call in the OOM killer.

The crux of the patch is how to decide that memory pressure is occurring. mem_notify modifies shrink_active_list() to look for movement of an anonymous page to the inactive list, which is an indication that some will likely be swapped out soon. When that occurs, memory_pressure_notify() (with the pressure flag set to 1) will be called for that zone. When the number of free pages for the zone increase above a threshold—based on pages_high and lowmem_reserve for the zone—memory_pressure_notify() is called again, but with the pressure flag set to 0, effectively ending the memory pressure event for that zone.

If there are numerous processes waiting for a memory pressure notification, it could be counterproductive to wake them all at once—the "thundering herd" problem. To combat this, the patch set adds the ability to wake fewer processes than are waiting on the poll event, by adding the poll_wait_exclusive() function. poll_wait_exclusive() will in turn call add_wait_queue_exclusive() so that a member of the wake_up() family can be used that will limit the number of processes woken up. Previously, only poll_wait() was available, it uses add_wait_queue(), which does not provide this ability. Also, to reduce the frequency of processes waking up to reclaim memory, memory_pressure_notify() will only do that once every five seconds.

The /proc/zoneinfo output has been changed to include the mem_notify status. This can be used by a human for diagnostic purposes or by a program to check the current status of zones for memory pressure.

The embedded community has a lot of interest in seeing this feature get added to the kernel. Devices like phones and PDAs are often running close to their memory limits and the OOM killer is currently unavoidable when the user opens yet another application. With this patch in place, programs that use a lot of memory, but could get by with less, can be changed to free up their caches and the like when memory gets tight. As memory hungry programs get changed, other users will benefit as well.

The patch, submitted by Kosaki Motohiro, has been through several iterations on linux-kernel. The work was originally started by Marcelo Tosatti, with the fifth version recently posted by Kosaki. Previous versions have been well received and with relatively few comments on this iteration, it would seem to be getting close to being merged.

Comments (41 posted)

A new block request completion API

By Jonathan Corbet
January 29, 2008

The 2.6 block layer has traditionally provided a pair of functions by which a driver could indicate that an I/O request had been completed. A call to end_that_request_first() signaled the transfer of a certain amount of data and would return a value indicating whether the request as a whole was complete. Once all sectors in a request had been transferred, it was up to the driver to pass the request to end_that_request_last() for final cleanup. There was also a function called simply end_request() which might or might not end the entire request, depending on how much data had been transferred. This API has worked for a long time, but it has occasionally proved confusing for driver developers. It was also hard for drivers to communicate useful error information with this interface. So, as of 2.6.25, there will be a new way for drivers to indicate request completion.

After a block driver has transferred one or more sectors (or failed in the attempt), it should now make a call to:

    int blk_end_request(struct request *rq, int error, int nr_bytes);

Where rq is the I/O request, error is zero or a negative error code, and nr_bytes is the number of bytes successfully transferred. If blk_end_request() returns zero, the request is fully processed and the driver can forget about it. Otherwise there are still sectors to be transferred and the driver should continue with the same request.

blk_end_request() must acquire the queue lock to do its job. If the driver already holds that lock, it should call __blk_end_request() instead.

Block drivers traditionally did a number of housekeeping tasks between calls to end_that_request_first() and end_that_request_last(). These include calling add_disk_randomness() to contribute to the entropy pool, returning any tags used with the request, and removing the request from the queue. All of that stuff is now done within blk_end_request(), so drivers can forget about it. The occasional driver had to carry out other tasks between the completion of the request and its removal from the queue. For drivers with this kind of special need, there is a separate function to call:

    int blk_end_request_callback(struct request *rq, 
                                 int error, 
				 int nr_bytes,
			         int (drv_callback)(struct request *));

In this version, drv_callback() will be called (without the queue lock held) between the completion of the request and its final cleanup. If the callback returns a non-zero value, that final cleanup will not be done. This function will always acquire the queue lock - there is no version for drivers which have already taken that lock. In general, though, the use of the callback functionality is likely to be a sign that the driver is being tricker than it really needs to be.

This change was accompanied by a fair number of patches converting all in-tree drivers to the new interface. The old completion functions have been removed, so out-of-tree drivers will need updating before they will work with 2.6.25.

Comments (none posted)

Linus Torvalds Linux 2.6.24 ?

Steven Rostedt 2.6.24-rt1 ?

Adrian Bunk Linux 2.6.16.60 ?

Jeremy Fitzhardinge x86: ignore spurious faults ?

Jeremy Fitzhardinge x86: separate pmd lifetime from pgd ?

Ingo Molnar x86 arch updates for v2.6.25 ?

Andi Kleen [0/9] Latest GBPAGES patchkit for 2.6.25 ?

Haavard Skinnemoen AVR32 PWM driver and example user ?

monstr@monstr.eu Microblaze init port ?

Paul Mundt sh updates for 2.6.25-rc1 ?

Ingo Molnar scheduler changes for v2.6.25 ?

maxk@qualcomm.com CPU isolation extensions ?

pierre.peiffer@bull.net IPC: code rewrite + new functionalities ?

Mathieu Desnoyers LTTng Userspace Tracing, vDSO ?

Mathieu Desnoyers Instrumentation Support Enhancement (2.6.24-rc8-mm1) ?

Steven Rostedt mcount and latency tracing utility -v6 ?

Steven Rostedt mcount and latency tracing utility -v7 ?

Bodo Eggert Introduce softpanic V.2 ?

Greg KH driver core patches against 2.6.24 ?

Greg KH USB: mark USB drivers as being GPL only ?

Shaohua Li PCIE ASPM support - takes 3 ?

Chandra Seetharaman scsi_dh: Move dm device handler to SCSI layer ?

Bartlomiej Zolnierkiewicz IDE updates part #1 ?

Bartlomiej Zolnierkiewicz IDE updates part #2 ?

Mauro Carvalho Chehab V4L/DVB updates for 2.6.25 ?

Roland Dreier First InfiniBand/RDMA merge ?

James Bottomley SCSI updates for 2.6.24 (part 1) ?

Arjan Opmeer Version 3 of Elantech touchpad driver for kernel 2.6.24 ?

Jussi Kivilinna : Driver for Wireless RNDIS USB devices. ?

Haavard Skinnemoen dmaengine: Slave DMA interface and example users ?

David Sterba ipwireless: driver for 3G PC Card ?

Wim Van Sebroeck v2.6.24 watchdog patches ?

Takashi Sato ext3 freeze feature ?

Liu Hui [PATCH] The second patch of acl supporting for btrfs(patch for btrfs-unstable) ?

Andi Kleen [0/18] Implement some low hanging BKL removal fruit in fs/* ?

KOSAKI Motohiro mem_notify v5 ?

Christoph Lameter [RFC] MMU Notifiers V1 ?

Christoph Lameter [RFC] MMU Notifiers V2 ?

Christoph Lameter [RFC] MMU Notifiers V3 ?

Fengguang Wu writeback: speed up writeback of big dirty files ?

James Morris security: add iptables "security" table for MAC rules ?

Andrew G. Morgan per-process securebits ?

Robin Holt Enhance mmu notifiers to accomplish a lockless implementation (incomplete). ?

Andrea Righi [PATCH] cgroup: limit network bandwidth ?

Joerg Roedel [PATCH][RFC] SVM: Add Support for Nested Paging in AMD Fam16 CPUs ?

Serge E. Hallyn user namespaces: introduction ?

Rafael J. Wysocki 2.6.24-rc8-git5: Reported regressions from 2.6.23 ?

LCA: The state of Debian

By Jonathan Corbet
January 28, 2008

The Debian miniconf is one of the oldest of linux.conf.au traditions. This year, Martin Krafft was the person who - with short notice - got to lead off this gathering with the "state of Debian" talk. Debian, as always, is an active project, and it seems that much is going well.

The Debian security team has grown over the last year. Martin noted that Debian, for all practical purposes, had no security support for a period after the ~~Etch~~ Sarge release. Those days are over, though, and Debian's security support is, once again, solid. There is now good security support for the testing distribution as well; in fact, testing updates often come out before those for the stable distribution. That result comes from the fact that testing updates do not need to support all architectures and there are fewer embargo issues.

The upcoming Lenny release, it was noted, will have implemented most of the features called for in the security-hardening specification.

The state of translations is good; Debian supports 58 languages now, and may support 77 by the Lenny release. The Smith Review Project has been working through the package base, ensuring that package descriptions are, well, descriptive, in proper English, and easily translatable.

On the ports side, the Sparc32 port has been officially retired; to the dismay of relatively few users. The Lenny release will include a new port: Debian GNU/kFreeBSD, which is based on the FreeBSD kernel. Martin thought this port would appeal to those Debian users who have been complaining about the increasing "multimedia orientation" of the Linux-based distribution.

Much work is going into making the package repository more searchable. The debtags project, which is putting a set of standardized tags onto packages, is relatively advanced. This effort will address a number of longstanding problems, like the fact that a search for "image editor" does not turn up GIMP, which is an "image manipulation program." Debtags will also make it possible to search for packages which are related to other packages. There is also the apt-xapian-index project, which is working toward indexing all package metadata and providing a fast search capability.

Other bits of current status:

The debian-med project - building a version of Debian aimed at the medical industry - is headed toward a 1.0 release.
The Debian mirror network is growing. There are six new primary mirrors, and around 100 new secondary mirrors.
Lenny will use UTF-8 nearly exclusively. Developers are working on fixing the remaining packages which do not yet support UTF-8.
The venerable dselect is almost retired. There are still dselect users out there; Martin suggests that all of those folks move to aptitude.
There are a lot of new games coming into the distribution.
The Etch-and-a-half release will be happening soon. This is a version of Etch which offers a 2.6.24 kernel - needed to make Etch work on newer hardware. The original 2.6.18 kernel will remain an option for Etch users.

Looking forward to 2008, Martin noted that the Lenny release is currently planned for December. Lots of emphasis on "planned" - given Debian's history in this regard, few people actually expect the release to happen on time. Martin did say that things have been getting better in this regard, with Etch being "only" four months behind schedule. A Lenny release which is only a couple months late seems feasible.

Something which is just coming into play is the new "Debian maintainer" status. Unlike full developers, maintainers cannot vote, have no access to the debian-private list, and do not have much access to the wider Debian infrastructure. About all they really can do is upload a specific set of packages. So the "maintainer" designation is good for those who want to maintain a small set of packages, but who are not looking to be an active participant in Debian as a whole, and who do not want to run the "new maintainer" gauntlet.

Martin was asked whether there was any thought of downgrading any existing developers to maintainers. He said that there was some interest in doing that. There are currently just over 1000 developers, all of whom have full access to the repository. Some 400 of those are inactive, but they still possess a key which lets them make changes to the system; this is a clear security issue. The MIA project is looking to identify these people and, eventually, move them to inactive status. On the issue of whether the project would be forcibly downgrading active developers who, for whatever reason, are not entirely welcome in the community, Martin says that will not be happening. There is just no way to do it without bringing massive disruption and flame wars, and nobody wants that.

There was also a question on the role of the debian-private list. The biggest use of debian-private, according to Martin, is vacation announcements; developers need to let the project know that they will not be around, but they do not wish to announce their absence to the wider world. There are some other discussions there too, of course. Current policy says that debian-private discussions will be disclosed after three years in the absence of a request to the contrary. There's an effort afoot to disclose older traffic from before the adoption of that policy, but that requires the assent of all of the participants.

The debian-women project, unfortunately, is currently stalled; the main participants have not had the time to push things forward. The #debian-women channel remains active, though, and is generally a nice and supportive place to be. There are currently about twelve active female contributors to Debian. Martin thinks that women are becoming more present in general, though, and he stated that "the Debian cowboy days are done."

On the packaging front: the packages.qa.debian.org site has been redone in "beautiful CSS." There are now RSS feeds for those who want to follow the status of specific packages. A new "LowThresholdNMU" flag has been added; this is essentially a statement on the part of the maintainer that he will not get offended if others upload fixes to the package. Packages can now use bzip2 compression. There has also been a major rework of the shared library infrastructure, which now looks at actual symbol use when determining shared library dependencies. This change should make it possible to install individual packages from testing into a stable system without having to update all of the libraries that package uses.

There is a growing trend toward team maintenance, especially for the larger package sets. This approach increases the robustness of the system and minimizes problems with MIA maintainers.

Version control systems are working their way into the Debian infrastructure. Packages can now have a set of Vcs-* headers which point to the upstream source repository; these can be used, for example, with the debcheckout command to clone the source repository without having to know anything about the source management system used. Version control systems also offer a solution to the current problem of "hackish packaging tools" being used by many developers. In the future, source packages might just include a shallow repository which can be fed straight to git (or some other system). This project is stalled at the moment, but Martin thinks it will go somewhere; it would be nice if the distributors could come up with a common scheme that they can all use.

The final topic in this session was a question from the audience on whether Debian might ever go to a shorter release cycle. The projected 18 months for Lenny seems like a step in that direction, but 18 months is still quite a bit longer than the cycles used by many other free distributions. Martin thinks that going shorter is unlikely. The fact of the matter is that distribution upgrades are a hassle, requiring a fair amount of administrative attention. Ubuntu may have made some progress with its use of upgrade scripts, but the basic problem remains. On top of that, shorter release cycles would necessarily lead to a shortening of the time for which security updates are available for any specific release. And that, in turn, would force users into more frequent updates whether they want to do that or not. So one should not expect six-month release cycles from Debian anytime soon.

Comments (38 posted)

Mandriva Linux 2008 Spring Beta 1 "Ophrys" released

The first beta of Mandriva Linux 2008.1 has been released. "The third pre-release of Mandriva Linux 2008 Spring is here. This pre-release brings available KDE 4.0.0 final (in the repositories, not on the discs), a new XML-based package metainformation system, out-of-the-box support for multimedia keys on many common keyboards, new NVIDIA and ATI drivers, kernel 2.6.24 RC8 (with ALSA 1.0.16 RC1), and more."

Date(s)	Event	Location
February 6 February 10	O'Reilly Money:Tech Conference	New York, NY, USA
February 7	Frozen Perl 2009	Minneapolis, United States
February 8 February 10	Southern California Linux Expo	Los Angeles, USA
February 10 February 13	NDSS Symposium 2008	San Diego, CA, USA
February 11	Florida Linux Show 2008	Jacksonville, Florida, USA
February 11	Open Source Software (OSS) and the U.S. Department of Defense (DoD)	Alexandria, VA, USA
February 13 February 15	German Perl-Workshop	Regionales Rechenzentrum Erlangen, Germany
February 16	Frozen Perl 2008 Workshop	Minneapolis, USA
February 19 February 20	Linux Developer Symposium	Beijing, China
February 19 February 20	Files and Backup	London, UK
February 22 February 24	freed.in/2008	Delhi, India
February 23 February 24	Free/Open Source Developers' European Meeting 2008	Brussels, Belgium
February 23 February 26	Linux World Mexico	Mexico City, Mexico
February 25 February 26	2008 Linux Storage and Filesystem Workshop	San Jose, CA, USA
February 25 February 29	NEW PHP 5 and PostgreSQL Bootcamp with Mark Fenoglio	Atlanta, Georgia, USA
February 25 February 27	German Perl Workshop	Frankfurt, Germany
February 28 March 1	Linux Audio Conference	Cologne, Germany
March 1 March 2	Chemnitzer Linux-Tage 2008	Chemnitz, Germany
March 3 March 6	O'Reilly Emerging Technology Conference	San Diego, CA, USA
March 3 March 6	Drupalcon Boston 2008	Boston, MA, USA
March 4 March 9	CeBIT Germany	Hannover, Germany
March 8 March 14	Asia OSS Conference & Showcase 2008	Guangzhou, China
March 11 March 12	4th AustralAsian Cleantech Forum	Melbourne, Australia
March 14 March 16	PyCon 2008	Chicago, IL, USA
March 15	FSF Associate Members Meeting	Cambridge, MA, USA
March 16 March 19	BossaConference 2008 - International Conference on Open Source Software for Mobile Embedded Platforms	Pernambuco, Brazil
March 16 March 21	Novell BrainShare 2008	Salt Lake City, UT, USA
March 16 March 20	Free Software and Open Source Foundation for Africa	Dakar, Senegal
March 17 March 20	Eclipse Community Conference	Santa Clara, CA, USA
March 17 March 20	Spring VON.x Conference	San Jose, CA, USA
March 19 March 20	LinuxWorld Expo 2008 Brussels	Brussels, Belgium
March 24	SDForum Global Open Source Conference	San Francisco, CA, USA
March 26 March 28	CanSecWest 2008	Vancouver, BC, Canada
March 26	Document Freedom Day	Everywhere, Worldwide
March 29 March 30	PostgreSQL Conference East 2008	College Park, MD, USA
March 31 April 2	UKUUG Spring 2008 Conference - Dynamic Languages	Birmingham, England
March 31	2008 European Workshop on System Security	Glasgow, Scotland
March 31 April 2	UKUUG Spring 2008 Conference	Birmingham, England
March 31 April 2	Sharkfest Wireshark Network Analysis Summit	Los Altos Hills, CA, USA
April 2	First meeting UKUUG PostgreSQL SIG	Birmingham, England
April 3 April 4	E-Mail Systems Conference 2008 (Exim and other mail systems)	Birmingham, England
April 4 April 5	openSUSE Packaging Days II	IRC, Everywhere

LWN.net Weekly Edition for January 31, 2008

Security

New vulnerabilities

gforge: cross-site scripting

icu: arbitrary code execution

kernel: several vulnerabilities

mysql: buffer overflows

netkit-ftpd: denial of service

ngircd: denial of service

pulseaudio: ignores setuid() return value

tikiwiki: multiple vulnerabilities

yarssr: arbitrary code execution

Kernel development

Brief items

Kernel development news

Patches and updates

Kernel trees

Architecture-specific

Core kernel code

Development tools

Device drivers

Filesystems and block I/O

Janitorial

Memory management

Security-related

Virtualization and containers

Benchmarks and bugs

Distributions

News and Editorials

New Releases

Distribution News

Debian GNU/Linux

Fedora

Gentoo Linux

SUSE Linux and openSUSE

Other distributions

New Distributions

Distribution Newsletters

Newsletters and articles of interest

Interviews

Development

System Applications

Clusters and Grids

Database Software

Security

Telecom

Miscellaneous

Desktop Applications

Audio Applications

Desktop Environments

Educational Software

Interoperability

Mail Clients

Video Applications

Web Browsers

Languages and Tools

C

Caml

Lisp

Perl

Python

Tcl/Tk

Editors

Libraries

Linux in the news

Recommended Reading

Companies

Linux Adoption

Interviews

Reviews

Announcements

Non-Commercial announcements

Commercial announcements

New Books