![[LWN Logo]](http://old.lwn.net/images/lcorner.png)
![[LWN.net]](http://old.lwn.net/images/main.png)
|
|
|
Bringing you the latest news from the Linux World.
Dedicated to keeping Linux users up-to-date, with concise
news for all interests
 Sections: Main page Security Kernel Distributions Development Commerce Linux in the news Announcements Linux History Letters All in one big page
Other LWN stuff:
Archives/search
Recent features: Here is the permanent site for this page. See also: last week's LWN.
|
Leading items and editorialsFun with trademarks. As if to prove that the U.S. is not alone in presenting obnoxious intellectual property challenges to free software, Germany has turned up a couple of interesting cases on its own. Both of these are challenges relating to trademarks; there are likely to be many more where these came from.
The first concerns the MobiliX site, which
is maintained as a mobile Linux resource by Werner Heuser. It seems that
Mr. Heuser, who has even registered the "MobiliX" trademark in Germany, is determined to fight this case. We wish him the best of luck in this battle. Meanwhile, SuSE has been hit by a restraining order blocking the distribution of SuSE Linux in Germany. This order results from a suit by our good friend Guenter Freiherr von Gravenreuth, once again. The claim is that the KDE "Krayon" package violated Crayon's trademark in Germany - even though SuSE does not ship Krayon. According to this News.com article, this issue was resolved just before LWN went to "press." "SuSE was not required to submit payment for any license fees." So that case, at least, was resolved relatively easily. The next one may not be. Free software is available globally. If you were to look at the names found on any given distribution, chances are good that a large number of them would resemble trademarks somewhere in the world - especially if you are a lawyer looking for things to litigate. It will not take too many of these cases before people and companies start to take down their free software web sites, and to start pulling programs out of distributions. Trademarks, thus, are a great opportunity for those who wish to harass free software developers and distributors. This is not going to be an easy problem to solve, to say the least. It is time to be done with buffer overflows. The recent Microsoft XP vulnerability, the one that exposes almost every system connected to the net, was caused by a buffer overflow. It is easy to sneer at Microsoft for allowing such a vulnerability into their code, but one should look at this week's LWN security page before sneering too hard. Linux distributors have done a good job at rushing out fixes for the remotely exploitable vulnerability in the widely-used mutt mailer. That vulnerability is, of course, a buffer overflow problem. We in the free software community claim to have programs which are more secure than the proprietary variety. In some ways, that is true: the mutt updates came out much more quickly than the XP fix, which took five weeks. But we still ship a lot of code which contains vulnerabilities, including trivial problems like buffer overflows. It is time that this practice came to an end. If the free software development process is truly better at examining its code, if many eyeballs really make all bugs shallow, then we should be able to eliminate this class of errors from our systems. Indeed, it is interesting to ponder why such errors still turn up with amazing regularity. One answer, certainly, is that the number of eyeballs looking at free code is frequently exaggerated. Auditing code is a tedious and often thankless task; most hackers would rather be working on the next great word processor, network protocol, or scheduling algorithm. Once you can understand a given body of code well enough to figure out where the buffer overflows are, you are in a position to do something more interesting. We, as a community, need to do more to encourage auditing of code for buffer overflows and other vulnerabilities. There are projects out there - consider the kernel janitors project or OpenBSD - which show that developer communities can do this sort of work. Code auditing can be a good way for a new developer to learn his or her way around a project's source; encouraging auditing and recognizing those who find (and fix) problems could go a long way toward eliminating buffer overflows as something that Linux users need to worry about. Another obvious answer is that the languages used for much free software development make buffer overflows too easy. C and C++ will not be going away anytime soon; they offer a sort of control and power that is needed in too many places. But anybody contemplating a new development should think long and hard about using an implementation language that is inherently resistant to buffer overflows. Many such languages exist (consider Python, Perl, Ruby, Java, etc.); it should be possible to find one to suit almost any taste. More modern languages can be a lot of fun to program in, and they are free of whole classes of problems that bother C and C++ programmers. Imagine the comfort of running an operating system which had not experienced a buffer overflow vulnerability for a year or more. This is a goal that should be attainable by a community such as ours. A serious effort to eliminate these embarrassing and avoidable errors would do much to establish Linux's credibility as a truly secure system. Can we really afford not to do it? Inside this LWN.net weekly edition:
This Week's LWN was brought to you by:
|
January 10, 2002
|
Copyright © 2002
Eklektix, Inc., all rights reserved![[Obelix]](obelix.jpg)
Mr. Heuser is the subject of 
Next: Security