Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for August 11, 2005Interview: Eben Moglen Attending Linux trade shows is a lot of hassle, particularly when you have to drive a couple of states to make it to the location. However, this is greatly mitigated by the fact that one has the opportunity to speak face to face with some of the more interesting people in the Linux community. This week at Linux World Conference & Expo, I had the chance to speak with Eben Moglen, President and Executive Director of the Software Freedom Law Center. The interview touched on the Software Freedom Law Center, the revision process for the GPL version 3 and several other topics.LWN: What's the status of the Software Freedom Law Center, what kind of activities are going on, and its funding?
The status is making a law firm is an interesting activity, particularly if
you're building a small business on Manhattan island. I've spent more time
on real estate and physical details of making it work than I thought we
would, but we're successfully housed and we're hiring lawyers and we've
been recruiting clients and releasing some press about the clients we've
recruited and that process is scaling up, we expect Dan Ravicher my junior
partner and I to have at least two more lawyers, maybe three more hired
during the next few months and we will be looking to hire some young
people, freshly graduating from law school this coming spring and
entertaining our first international fellows starting this year.
As for funding, we've received now two rounds of funding from OSDL, which has been acting as our agent for collecting from a number of vendors, they have been gratifyingly reliable in the funding of our firm, and I have no reason to believe that there will be any difficulty. I think the principle that better support for developers is good for business is now firmly in everybody's mind and we have been very graciously entrusted with the task of making that happen. LWN: A while back, you said something about getting an answer from Linus on the Linux kernel license. Since there is a COPYING file that makes it clear that the kernel is governed under the GPL, where's the uncertainty?
If the kernel is pure GPL, then I think we would all agree that non-GPL,
non-free loadable kernel modules represent GPL violations. Nonetheless, we
all know that there are a large number of such modules and their existence
is tolerated or even to some degree encouraged by the kernel maintainers,
and I take that to mean that as an indication that there is some exception
for those modules.
The kernel also maintains a technical mechanism, namely the GPL-only symbols and tainting structure, which seems to suggest an API for the connection of non-GPL'ed code to the kernel, which also seems to me a strong indication of the presence of an exception. The difficulty as a lawyer, even a lawyer that is reasonably knowledgeable about these matters, is that I don't understand what the terms of that exception are. So, say I want to audit a system, say an embedded product, in which I find non-GPL loadable kernel modules present, how do I know whether that fits within an exception which is legitimately available to third parties and when it is not? Linus has said over the years a number of things about how he would not object to anything that was not in obvious bad taste, or ugly, or awkward or unacceptable and I understood, I think, what he meant at each of those particular times. But it would be helpful in applying an analysis from a lawyer's point of view, and think about the problem. One very important area is the problem faced by people who make software-controlled radios, which they want to run in systems which make use of the Linux kernel and other GNU and free software. Those parties may feel they're under regulatory orders not to release source code modules, because regulators in Japan and Europe and the United States have all, to differing degrees, made clear to manufacturers of radio transmission hardware that if they allow after-market modification that violates spectrum control regulations they may be in trouble. The Japanese in particular have been very strong in their wording. So then there are parties in the world who think they are in legal trouble on one side with the regulators if they do release source code for loadable kernel modules that drive their software-controlled radios, and they don't know if they're in legal trouble on the other side if they don't release source code. For those parties, in particular, it would be very helpful if the kernel developers had decided to formalize the nature of their exceptions, and the Free Software Foundation and I have made a few attempts to discuss that matter with kernel developers. I had conversations with Ted Ts'o, I talked to Linus about it and I understood there were some reluctances to clarify, in a full and complete way, what was going on. There may have even been disagreements among kernel developers about that, I wouldn't know. But I continue to think that it would be useful, for a whole variety of people who are trying in good faith to do the very best they can, and who may be navigating some dodgy legal territory, for them to be able to refer to something beyond the COPYING file which -- with all due respect -- I think probably doesn't contain all the terms that are relevant to the use of the kernel. LWN: So, if the kernel is covered solely by the GPL, you would see proprietary modules as an infringement?
Yes. I think we would all accept that. I think that the degree of
interpenetration between kernel modules and the remainder of the kernel is
very great, I think it's clear that a kernel with some modules loaded is a
"a work" and because any module that is dynamically loaded could be
statically linked into the kernel, and because I'm sure that the mere
method of linkage is not what determines what violates the GPL, I think it
would be very clear analytically that non-GPL loadable kernel modules would
violate the license if it's pure GPL.
LWN: Should distributors of proprietary modules then be worried about infringement?
As a matter of fact, I think they are worried about it, and that's why I
think that clarifying the license terms would be helpful. If there are no
exceptions and that were stated very clearly then they would know that's
not the way to do what they're doing. If there are some exceptions
available, for example for people who have no legal choice, they'd like to
know what those rules are and I'm sure lots of other lawyers around the
community would too.
LWN: The Free Software Foundation put out a press release about a year ago saying that the reason that SCO was attacking the Linux kernel and not attacking GNU was because of the FSF copyright assignment policies of the FSF, do you still see it that way, and why is the kernel vulnerable when GNU is not, in that case?
I think what I said then was not that the reason was, because I truly
didn't know what the reason was why Mr. McBride did anything at all. I
think what I said was, I took from the fact that they were fulminating a
great deal about the illegality of the GPL and the badness of the Free
Software Foundation, and yet weren't objecting to our code was because they
knew it would be particularly easy to show that they were wrong.
I think that what I said was, that a process of taking a copyright assignment process from each contributor, accompanied by a legal indemnity, promising that the code was the code of the contributor and that there was nobody else with a dominating interest in it and doing so at the point of an indemnification promise to the Free Software Foundation produced a very strong chain link fence between us and claims of the kind that SCO was throwing around and I thought that constituted an indication of a cautious and prudent model of how to put free software together which Stallman had been following since long before I worked with him in the construction of the GNU Project. That didn't mean I think, that it was the only way to put together code that is strong, but where it works, it's a highly desirable model to pursue. Linus eventually found another formula, which suited his view of the way the kernel development process works for introducing some accountability in the contributions process, and I thought that was a very good idea, and I said so. I think that if all the free software in the world were assembled in the most prudent and conservative fashion, that Mr. McBride and his colleagues would have found no place to even begin with the FUD with which they began. I think it's also important to point out that we all thought those accusations were baseless to start with and had good reasons to think they were baseless to start with. There wasn't anything wrong with how the kernel is put together. If there was a statement to make, it was simply the way the kernel is put together doesn't prove on its face the cleanliness of how it was put together with the degree of strength that otherwise could have been mustered. I would advise clients of the Software Freedom Law Center, in light of SCO and many other things to begin their projects in ways that document and protect more carefully that structure of how free software is put together. But I understand completely how Linus Torvalds, living in Finland as a University of Helsinki undergraduate, unadvised by counsel, would not have chosen what I would now recommend to my clients to choose. LWN: You made a comment about patent holders shaking down users of free software for royalties. I haven't heard of any situations where this is happening, can you tell us how bad the problem is, why it's not being made public when it happens?
Well, I think I can say why it isn't being made public, when a manufacturer
of products with embedded free software, or user on a large scale of free
software is the subject of claims such as this, from a company such as
Microsoft, if they take a license and pay it's because they want peace and
quiet. If what they want is peace and quiet, they'll be quiet about how
they procured peace. The result of which, we won't hear except in an
indirect way. That's why it's not public.
Why it's not a good idea is that each one of those parties that procures peace and quiet for itself is doing harm to the others in the ecology. Each one that takes a license strengthens the apparent patent claim that they are paying tribute on. The result of which is to strengthen the hand by which the troll tends to pick somebody else up later on. From an ecological point of view, we're concerned about the health of the entire community. You'd like to say to such people, before you pay that license fee, can you talk to about why that patent FUD may be just FUD? Could we discuss what we know about the patents held by the parties shaking you down? Could we present to you why maybe those patents aren't very strong and maybe not an appropriate basis for the payment of tribute. In other words, could we maintain a united, consolidated front. The problem with the private license deals, they affect our solidarity and our ability to act defensively as a community together. And whether they're done publicly or not by the party who took the license, there's always a risk they'll be trumpeted by the patent holder as a sign of the strength of its patent and the degree to which other people should be afraid. So, when I have some reason to believe that some such situation is in progress, I often make an attempt to communicate with the party taking out a license, and often they won't talk and they prefer peace and quiet. I think that more respect for the needs of the community would be an appropriate leaven in their decision-making process? LWN: How bad is the problem? Is this happening a great deal?
Well, I'm not in a position to say how often it's happened of course, since
I'm sure I only know about a fraction of when it's going on. It's pure
chance when we discover it, sometimes. I think it's bad for the reason I
have suggested, that everybody knows... the patent problem is a real
problem, and it needs a real solution. And you see people like the Open
Source Development Labs stepping up and trying to create collaborative
means to address the problem. Everything that subtracts energy from that
attempt to collaborate to solve the problem, is in itself making the
problem worse.
Without unduly criticizing businesses that are making business decisions, they're paying money to have peace, which is perfectly understandable to do and may be culturally particularly appropriate in certain national settings, I think that overall it creates difficulty for us, it aggravates the problem of patents overall. LWN: There's a draft bill in the House right now, that would restructure the patent system, would it be good for free software?
It would not be bad for free software if it passes. That is to say there's
nothing in that bill that aggravates the problem. Many things that were
originally proposed in that bill that would have been good have been
removed in the process of discussion.
My particular analysis is that, at the moment, the legislative process is stalled. I do not expect any movement in that legislative process. I think that, for the moment, that initiative is in the deep freeze. My analysis is that the power of pharma to control what happens to patents in the United States Congress is nearly absolute. The Princeton health economist, Uva Rinehart, who was a major advisor to the Clinton task force and is one of the most knowledgeable health care economists in the United States referred recently in a National Public Radio report I was listening to, to the pharmaceutical companies' "substantial equity stake in the United States Congress," and I thought that was a very elegant way of putting it. My belief is that until such time as there is a deal which includes the pharmaceutical companies, there is very little enthusiasm in the United States Congress for meaningful patent reform. I must say, as a person who represent parties who are very afraid of what patents can do to them, I think that this operation is very largely a sideshow. I think it was intended to give the impression that things were being done, and I think that people, in good faith, who want good outcomes, nobly put their shoulders to the wheel and tried to turn it. But I do not believe it will turn this time. I don't think it's going to turn until we make some serious attempt either to disengage the interests of pharma from IT and pursue sector-based relief from the patent problem or until we step up to the problem that the patent system doesn't work very well under 21st century conditions and no matter what the pharmaceutical companies think it needs serious reform. LWN: You've encouraged free software developers to get patents on unique ideas. Is that happening much, and what resources are there for developers who want to obtain patents?
The grave difficulty in operating in this direction, which Mr. Stallman and
I have been thinking about for years now, in order to be efficient in
obtaining patents, you need to associate patent lawyers with patent agents
with engineers in the very early stages of design and development of
inventions.
You need to have people there right along, it's very inefficient to try after a project is over to develop the patent applications. Moreover, in the United States patent law, once you have gone on sale, which includes public distribution of free software, you have a year to file a patent application and after that you may not file at all. The consequence of which is that there are both resource constraints and deadlines, which are very serious given the way that the free software development process works. Having patent agents and lawyers working along side developers is not a possibility. It's not efficient and it's not the way our community operates. The result is that the process of getting patents for free software, to build a pool, is almost impracticable while the developer community is spread very thin and very little of it works for large technology businesses with established processes for the getting of patents. On the other hand, resources may flow towards that in the same way that they have flowed towards the Software Freedom Law Center. I think that one of the most important things said in the OSDL announcement yesterday is that there would be resources for patent prosecution, that is for getting patents, available to developers who came forward and wanted their patents to go into the patent commons. That represents the first significant movement behind patent prosecution, behind getting patents. It's one of the things I hope people will notice about what OSDL has said, because I think it's an important strategic advance. Will it work in that sense across the enormous range of free software projects? No, I don't think so, we're just at the beginning, we'd have to scale that in many different directions. But, in some crucial projects, important to our commercial partners in this process, and large numbers of users, and tightly coordinated development teams that have worked in large technology companies and know how the patent-getting processes work, in a range of conditions that are satisfied only in some parts of our community, I think there will be some real progress. I think you will see our inventions patented and there will be some cross-licensing negotiations that will be effective for us in gaining some use of other people's patent claims free of legal difficulty. LWN: In the framework you talked about, these patents would be assigned to the commons, so that they couldn't decide to abuse them.
One of the things we need to do is arrange all of the legal infrastructure
so that it works well for everybody. Yes, I think that's a reasonable thing
to expect, there will be safeguards to prevent that kind of change of
heart...
LWN: Let's talk about DRM. If the GPL requires distribution of scripts that control compilation and installation of an executable, does that extend to the binary keys for DRM?
I think the answer to that question is no. Under the existing GPL 2, the
better argument would be that those are not covered by the definition of
complete and corresponding source code under section 3 of the license. One
could change that definition in a future version of the GPL, and say, for
example, it's a straightforward idea, you could say the encryption keys
that make it possible to run this software on the hardware on which you are
receiving the software.
It is a possible approach. I think there are very significant difficulties with it, including the possibility we would pinch off a whole system of hardware in the world and say "free software doesn't run there." I think that might be a strategic mistake for the free software world, to say "we are going to write off a whole generation and form of hardware and not even attempt to bring freedom there..." I think we would risk leaving a whole lot of people in a condition of unfreedom for a long time. I think unless we are prepared to be more sophisticated in our approach to this -- this is a very ham-fisted approach, the idea that you buy a computer and are not allowed to be in charge of it. It's a very anti-consumer thing to do. Instead of building an electric fence around it, as though it were some kind of bad place we don't want to go. I think we have a duty to bring freedom there if we can, and we need to empower consumers to reject such hardware and my hope is that in a future version of the GPL, we will devise something elegant and effective at using the gravitational force of freedom to unlock that place over there, and not just seal it off. LWN: You talked a bit at the beginning about software-controlled radios and why they're important, do you want to add to that?
I've published pieces about that. If we are interested in freedom,
generally, one of the things that we have to recognize about the 20th
century is that there was a great degree of unfreedom that was generated by
control over spectrum. Governments around the world either controlled
spectrum themselves or delegated control to a small number of powerful
people, and that affected 20th century politics very, very deeply.
It was also a technical response to a problem that doesn't exist with intelligent devices that exist in the 21st century... the technical rationale for the concentration of spectrum in a few hands is gone, and there never was a social rationale for that concentration of spectrum. It was never the case that the public trust that held the common property of the airwaves needed to be dealt with in a concentrated fashion for social or political reasons, the only justification ever given was a technical one. So from my point of view, the world of devices that know about the spectrum and deal with it intelligently can promise more democracy in media than we ever had before, just as the web did for publication of text and is now doing for video. We need to be alert to the fact that the way we deal with software-controlled radios and the ability for people to use the spectrum themselves the way they want to, is a very important political and social issue in the 21st century. That's why I pay very close attention to how the free software world interacts with the world of spectrum control and regulation. 15 years from now, that's where the action is and I want to get the early stuff right if it's at all possible to do so. LWN: Can we talk a little about the GPL revision process? When you did the GFDL process, some people thought they weren't listened to. What did you learn from the process?
I don't disagree with you that the process that was applied to the
publication and modification of the GNU Free Documentation License would
not work very well for the GPL version 3. And I think you've given reason,
there's a very small group of people who need to be satisfied by and to use
the license and in the other case, there's everybody on Earth... The GPL
involves affecting a much broader community of stakeholders, much more
various and much more complicated, we need to be in touch with that
community as much as we can, and I think the process on that scale is a
much different process.
I also should say that although it is true the number of people using the GNU FDL isn't that large, the number of people objecting to the FDL wasn't all that large either. There were a small number of people who wanted to say something and have their views heard. Whether they were heard or whether they thought they were heard is two different questions... I don't think there was a word written on that subject that I didn't read. Many words written on that subject I had no desire to respond to because I thought that response would only increase the intensity of the discussion... my goal in helping the Free Software Foundation construct a new GPL is to increase the lucidity without increasing the intensity. I hope there is a lot less shouting and a lot more thinking next time around by all parties. LWN: Do you think that's likely?
I do. If you want to know what I think we've learned, I think we've learned
some things about increasing the lucidity without increasing the
intensity.
We'd like to thank Eben Moglen for taking the time to talk with LWN.
The launch of openSUSE The SUSE Linux distribution has had a large and dedicated following for many years. SUSE users appreciate the combination of the distribution's administration tools, large selection of packages, and "German engineering." This distribution has always been relatively closed in its
development process, however. There is no development version available, and even
beta tests have been closed affairs. SUSE has not, as a rule, invited its
users to be a part of the development process.
The opening up of the SUSE distribution was bound to happen, sooner or later. Maintaining a major distribution is a major bit of work. But major distributions have user communities which can help with that work, and which can be the source of no end of good ideas as well. Bringing in the user community can improve the distribution, ensure wider testing, and, as a bonus, further bind those users with the distribution. People tend to be more enthusiastic about software which they have helped to shape and polish. Red Hat figured this out some years ago, and most other major distributions are created with a great deal of outside involvement. SUSE Linux is now attempting to follow a similar path through the openSUSE project, which was officially announced on August 9. OpenSUSE will play a role similar to Red Hat's Fedora; it is a free distribution, developed with community input, which will help to drive the development of SUSE's high-end commercial offerings. Unlike Fedora, however, openSUSE will continue to be available as a retail, boxed product. In this way, Novell hopes to make the distribution as accessible as possible. Since openSUSE is new, it lags Fedora in a number of ways. At the top of the list would be the lack of an ongoing development version of the distribution. The announcement of openSUSE included a beta release for openSUSE 10.0, which is a step in the right direction (see our review on this week's Distributions Page). The occasional beta release, however, is not the same as a bleeding-edge development repository along the lines of Rawhide, Debian unstable, or Ubuntu's "breezy." Your editor, who has not had a successful Rawhide update in some time, currently finds his enthusiasm for development repositories to be at a relatively low point. But the fact remains that making the current development version of a distribution available facilitates early testing and feedback. It also provides an experience some users want: riding the leading edge of a fast-moving distribution is a great way to taste - and participate in - the vitality of the free software community as a whole. The openSUSE "how to participate" page shows some parallels with the early Fedora days. The first and foremost way for people to participate at this time is to test packages and report bugs. Interested people are also encouraged to submit patches, write documentation, or apply for a job. There is currently no way for outside developers to apply changes or provide packages themselves; the roadmap page states that "a first version" of a build server will be made available in early 2006. Given the frustration experienced by would-be Fedora developers, the openSUSE folks would be well advised to get that infrastructure in place in short order. Some things are missing from the openSUSE site altogether. There is, for example, no discussion of how openSUSE will be governed. Who will make decisions on distribution policy, which packages will be included, etc.? Fedora, instead, launched with detailed plans for various sorts of advisory boards - and promptly ignored them all. More recently, Red Hat has been talking about loosening its firm grip on Fedora; very little has been said, instead, about just how independent openSUSE will be from Novell's management. Also missing is any discussion of the security update policy for openSUSE releases. SUSE's security response tends to be rapid and thorough. The same has traditionally been true of Red Hat, but Fedora brought with it a new policy on security patches. Updates tend to come quickly from Fedora, but the short period for security support makes Fedora a relatively difficult platform for any sort of production use. That suits Red Hat's goals nicely, of course - Red Hat is wanting to sell its enterprise support offerings. It would not be entirely surprising to see openSUSE take a similar path; hopefully the project will post a security update policy in the near future so that its users will know what to expect. If the openSUSE project is to be successful, it must find a way to attract developers and users, and to keep them happy. There is quite a variety of community distribution projects out there, and many of them do not have any apparent conflicts of interest with corporate goals. OpenSUSE will have to distinguish itself from those other distributions somehow. The openSUSE FAQ gives a hint as to how the project's leaders are hoping to proceed:
The openSUSE project explicitly looks beyond the technical
community to the broader non-technical community of computer users
interested in Linux... Only the openSUSE project refines its Linux
distribution to the point where non-technical users can have a
successful Linux experience.
The "only" claim is certainly debatable, but, with SUSE Linux as a base, the openSUSE project has a solid base upon which to build in that direction. There will always be room for a well-designed, robustly-built, user-oriented Linux distribution.
Some SCO notes It has been some time since the SCO Group has graced the LWN front page. That situation is just fine with us; there is no end of more interesting stuff happening out there. A couple of events this week merit a bit of attention, though. Even as it heads toward total irrelevance, the SCO Group is worth watching.SCO launched its annual SCO Forum (evidently a rather smaller event this year) with a delightful open letter from Darl McBride. The letter, in some ways, is classic Darl; full of bluster and easy to refute. It's almost like the good old days, before SCO's lawyers finally got him to keep his mouth closed. Others have taken on the task of writing detailed rebuttals of this letter; there is no real point in doing it here. What is truly worth noting in the latest open letter, however, is that it contains no threats to sue anybody. Darl, instead, seems to have concluded that he should maybe think about trying to sell some software. As a result, his letter is all about showing why OpenServer is better than Linux. It is FUD from one end to the other, but it is boilerplate commercial FUD of the type we have seen before. Darl seems to be working from the playbook that Microsoft discarded (as ineffective) some years ago. The "Linux has no support" line is a holdover from the 1990's. It didn't work then; there is no real reason for us to worry about it now. The SCO Group seems to have concluded that the litigation lottery ticket is not going to pay off, and so is putting its effort into plan B. Had the company done that a few years ago, it might have gotten somewhere. At this point, however, SCO seems unlikely to survive the countercharges being leveled against it. Novell's attempt to force SCO's remaining cash into an escrow account could, on its own, suffice to end the show - before companies like IBM and Red Hat even begin to get their licks in. Some additional amusement can be found in IBM's deposition of Erik Hughes, a SCO employee. One widely-reported outcome from this deposition (which was just recently unsealed) is that it seems likely that UnixWare's "Linux Kernel Personality" product included Linux kernel code for a couple of releases. If that is indeed the way of things, SCO may have been in violation of the GPL - at the same time it was charging copyright infringements by others. Remember the "Chris and Darl show" teleconferences from the early days of the IBM suit? One could almost get nostalgic about those bizarre exercises. Your editor would always try to get a question in, but, somehow, tragically, time always ran out before the question could be asked. In August, 2003, a message was sent to SCO's Blake Stowell and Chris Sontag asking a question which was not heard during the teleconference: noting that the 2.4 kernel was still available from SCO's FTP server, your editor asked just how SCO was able to reconcile its claims over the kernel with the GPL and its distribution of vast amounts of code over which it could have no possible claim. An interesting, private conversation resulted, in which a SCO employee stated that he did not think the GPL was valid. Nothing publishable ever came from the exchange, however, and your editor had long since forgotten about it. It can be a surprising experience to run across one's name unexpectedly in a legal document. IBM's lawyers, it seems, found that old message and brought it up in the Hughes deposition. Your editor, it seems, was one of a group of "long-haired smelly's" asking about the contradictions inherent in SCO's continued distribution of Linux while claiming that it contained SCO's proprietary code. The continued availability of the kernel on SCO's site has been well documented; the "smelly's" helped to document that SCO knew it was a violation of the GPL at the time. In retrospect, it seems clear that IBM's lawyers could have disposed of the SCO threat on their own. That notwithstanding, the community's "distributed defense" response to this attack is notable. As a group, we dug up vast amounts of information, poked holes in SCO's claims, and singlehandedly won the PR battle (which IBM could not engage in). Anybody contemplating an attack on the free software community will need to think long and hard about how to handle the community's response. On the other hand, the sheer buffoonery of SCO's attack presents a risk of its own: somebody may well decide that SCO's failure resulted from poor execution, rather than an inherently bad idea. Should that happen, we may have to go through all of this again. [Coming soon: the Grumpy and Malodorous Editor's Guide to All-Natural Deodorants.]
Page editor: Jonathan Corbet Security mod_spambot It has been known for years that spammers harvest web sites for email addresses to add to their lists. Various sites have responded by hiding or obfuscating email addresses found on their pages; some people go to extreme measures to keep their address from ever appearing on a page. One wonders what they are worried about; your editor only receives a mere 3-4000 spams per day to his highly-public email address, after all.Suffice to say that without SpamAssassin LWN would likely have collapsed under the flood years ago. Some folks have decided that it is time to take a more active stance against the harvesting of email addresses from web pages. The result is an Apache module called mod_spambot; version 0.47 was recently released. The idea behind this module is to detect accesses by address harvesters and shut them down. Unfortunately, the approach this module takes is too simplistic to work in many situations. mod_spambot is essentially a traffic throttling module. If a given site pulls down too many pages in a given time period (default is 100 pages in one hour), its access is cut off. There is also a "honeypot" option which will, instead, feed the (presumed) harvester a set of pseudo-random pages with bogus email addresses in them. This approach may well cut off some spammers, but anybody who has maintained a busy web site can see a few problems fairly quickly:
So throttling robots based on IP address will miss some attackers while blocking legitimate users of the site. It would be nice to prevent one's web site from being used as a resource by spammers, but this approach is not, yet, the way to that end.
Security news Update on RFID passports Bruce Schneier looks at current plans for RFID-enabled U.S. passports; it seems that things are headed in the right direction. "The most important feature they've included is an access-control system for the RFID chip. The data on the chip is encrypted, and the key is printed on the passport. The officer swipes the passport through an optical reader to get the key, and then the RFID reader uses the key to communicate with the RFID chip. This means that the passport-holder can control who has access to the information on the chip; someone cannot skim information from the passport without first opening it up and reading the information inside. Good security."
Greasing the wheel with Greasemonkey (SecurityFocus) Here's a SecurityFocus column on how the recent GreaseMonkey vulnerability was handled. "If we must continue the discussion to encompass the model of open source, then I have to say that the approach Greasemonkey took shows what makes open source great: openness. Throughout the whole painful process, information was available to those who needed it: developers, IT folks, users, and security pros. No one was kept in the dark, and all the details -- code, communications, thought processes, and so on -- were always available so that interested parties could make decisions based on facts instead of promises and conjecture."
New vulnerabilities gaim: buffer overflow
sysreport: insecure temporary file
ucd-snmp: denial of service
xpdf: denial of service
Updated vulnerabilities a2ps: input validation error
affix: two remote vulnerabilities
httpd: off-by-one overflow and cross-site scripting
apt-cacher: remote command execution
bzip2: race condition and infinite loop
ClamAntiVirus: integer overflows
cpio: directory traversal
CUPS: multiple vulnerabilities
cyrus-imapd: buffer overflows
dbus: information disclosure
dhcpcd: denial of service
ekg: multiple vulnerabilities
emacs21: format string vulnerability in "movemail"
enscript: arbitrary code execution
epiphany: Mozilla regression vulnerability
ethereal: dissector vulnerabilities
evolution: message crash vulnerability
fetchmail: buffer overflow
Foomatic: Arbitrary command execution in foomatic-rip
gdb: multiple vulnerabilities
gtk-pixbuf, gtk2: denial of service
gettext: Insecure temporary file handling
ghostscript: symlink vulnerabilities
glibc: tempfile vulnerability in catchsegv script
gnupg: information leak
gopher: insecure tmpfile creation
grip: buffer overflow
groff: insecure temporary directory
gzip: arbitrary command execution
heartbeat: insecure temporary files
htdig: cross site scripting
imap: buffer overflow in c-client
imlib2: buffer overflows
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||