Linux in the news
All in one big page
See also: last week's Letters page.
Letters to the editor should be sent to email@example.com. Preference will be given to letters which are short, to the point, and well written. If you want your email address "anti-spammed" in some way please be sure to let us know. We do not have a policy against anonymous letters, but we will be reluctant to include them.
November 8, 2001
From: Gleef <firstname.lastname@example.org> To: email@example.com, firstname.lastname@example.org Subject: Re: DMCA Issues Date: Thu, 1 Nov 2001 14:03:07 -0500 In Rip Linton's letter dated October 25, 2001, he writes: > > The DMCA does not stop us from documenting bugs or security > problems. It only prevents us from publishing code that bypasses the > security of an "effective" security device. The problem here is in this case there *is* accompanying code that bypasses an effective security device. Alan Cox's release notes aren't made in a vacuum, they are accompanying source code in the form of a patch to a kernel. Taking the Linux kernel source code and a security patch prior to that kernel release, and running "patch -R" with that security patch, can easily be argued to bypass the security of an effective security device. In my mind, it's far less of a leap to call a fixed security hole effective security than to call security measures in CSS or eBooks effective. In the case of kernel security fixes, The fix is a critical part of its own exploit. The confusing bit is that Alan's patches fix the security holes, but he doesn't talk about the details. The legal thing to do is to refrain from patching security holes. I would also consider this highly unethical. The ethical thing to do is to patch security holes. This is what Alan Cox is doing. If patching security holes is an ethical necessity yet illegal, than it should be recognized for what it is. Civil Disobedience. Civil Disobedience is far more effective if it's highly visible. Don't be quiet about security fixes. Shout them. Point out how this is illegal. Taunt the FBI to respond. Otherwise they win just by standing still. I urge anyone interested to read "Civil Disobedience", by Henry David Thoreau (1849). A copy can be found at: http://eserver.org/thoreau/civil.html This copy is split in two, be sure to read both sections. Yes, the scope of the injustices is less than those addressed by Thoreau, King or Ghandi. That doesn't change the fact that they are unjust, and injustice must be addressed. To address Alan Cox's release notes directly, yes the DMCA prohibits programs. The US Government acts as if code is equivalent to programs, and seems to act (in spite of Professor Felton's efforts) as if speech is not. Since Alan publishes code already, the extra speech about the code should not change whether or not the FBI would take an interest in prosecuting him. Alan is neither a US citizen nor a US resident, and should not bear the brunt of fighting a US law; I consider his stance of staying away from the US, until the DMCA no longer threatens him, prudent. That being said, whether he speaks about security issues or keeps silent does not change his legal status, and the security issues do need to be discussed. If he continues in his current mode (releasing security information only to non-Americans), and someone (within or outside the US) can help me access the security information, I will happily "smuggle" the information in and post them here (if the editorial staff would accept them) and in any other forum that will have them. -Gleef "What I have to do is to see, at any rate, that I do not lend myself to the wrong which I condemn." -Thoreau "First they ignore you, then they laugh at you, then they fight you, then you win." -Ghandi --
From: Mark Koek <email@example.com> To: firstname.lastname@example.org Subject: Response to letter to LWN Date: Fri, 02 Nov 2001 18:26:32 +0100 Cc: Rip Linton <email@example.com> Rip Linton <firstname.lastname@example.org> wrote: > The DMCA does not stop us from documenting bugs or security > problems. It only prevents us from publishing code that > bypasses the security of an "effective" security device. The whole point is that those two things may be one and the same. Source code is speech, and consequently, some speech is source code. The description of a security bug is an excellent example of something that may be trivial to convert to source code and thus, in practical terms, *is* code. And it's not just code, it's code that can be used to circumvent an access control system. Code, in other words, that it is illegal to publish under DMCA-like laws. Alan is not being as paranoid as it seems. I agree that it's unlikely that he'll ever be prosecuted for publishing details of a security bug, but I also think he is making a good point by stating that it is perfectly possible for the US DoJ to do it if they wanted to. Mark
From: "David Joffe" <email suppressed> To: email@example.com Subject: Re: Halloween revisited Date: Fri, 2 Nov 2001 06:40:36 +0200 Interesting article, I just want to add one point: > One could argue that future features in open source code could be > more credible, not less. Features in Microsoft code are hidden from > public view until they spring, fully developed, from the head of > Bill. Until a product is released, nobody really knows how > development is progressing It should be pointed out that this (MS springing fully developed features on an unsuspecting public) is most likely more due to Microsoft's monopoly than due to any natural side effect of commercial, proprietary software development in general. Microsoft's monopoly means that they *don't have to give a damn* what customers *really* want, instead, they are free to put into their software whatever is in *their* best interests (a good example is the recent "smart links" fiasco). These features are not there because they are best for customers but because they are best for Microsoft, but the only reason Microsoft can get away with doing this is (1) the public usually doesn't *know* any better, and (2) the public has no alternatives. In a truly competitive environment, software features would probably align more closely to what customers want. Right now the public will simply swallow whatever is dished up onto their plates. - David Joffe
From: firstname.lastname@example.org (Bryan Henderson) To: email@example.com Subject: bug reporting in noncommercial software Date: Tue, 6 Nov 2001 18:22:25 -0800 David Kastrup tells a great story in a letter to LWN about his inability to get his users to report bugs. People do, however complain about his program on Usenet and in personal emails. And maybe fix them privately. It's a catch 22 problem. Users don't waste their time reporting bugs because programmers don't fix them. Programmers can't fix bugs because people don't report them, or don't report them well. I myself rarely report bugs. I hate living with bugs, but I hate even more wasting my time. I don't want to spend 10 minutes gathering information, finding the bug reporting system, or typing into a form if I don't know there's someone listening. Experience shows there usually isn't. When I do break down and, as a last resort, report a bug, I write a very brief report -- one of those things tech support people laugh at because there's not enough information to do anything with it. But the point is that if I get a human being to respond and say, "I'm not aware of any problem like this and if you'll give me more information, I'll work on it," then I'm ready to cooperate. Kastrup wants to fix his bugs, so wants his users to report them. I have a suggestion: put some words in the bug reporting instructions giving the users confidence that there's some reason to report. E.g. "I fix every bug that is reported, usually within a week." Also, I myself always report a bug if there is a bug tracking system. I can see that 25 people haven't already reported it; I can see if bugs are routinely fixed; and even if I'm ignored, I have the good feeling that I'm telling the next guy who encounters the bug not to waste his time. -- Bryan Henderson Phone 408-621-2000 San Jose, California
From: "Knut Stolze" <firstname.lastname@example.org> To: David.Kastrup@t-online.de Subject: Re: Regarding: Open Source programmers stink at error handling Date: Fri, 2 Nov 2001 15:57:11 -0800 Cc: email@example.com David, Basically, I agree with you. But I believe you cannot generalize things the way you are doing. For example, I reported a few bugs to the KDE team. The result was that one (where KDE crashed the X server) got rejected right away with the comment "user error". From others, I never heard what was going on (accepted/fixed/not-fixed); others were rejected as "duplicates" but I didn't get any information about the duplicate, nor did I find anything in KDE's defect database; other bugs got fixed quickly, which was nice to see. But overall that's not very encouraging and one could easily consider it a waste of time trying to submit bug reports. In general, I still try to find some decent debugging environment integrated into the products, or see an automated test environment to prevent regressions. It might very well be that the products that have it are so stable for me that I never had a problem. So take this with a grain of salt, now... What I would expect is a specialized memory management and trace facility. I, as a developer myself, would like to know where in the code was a memory block allocated but never freed, including stack traceback; I would like to have direct control over the amount of memory allocated by using special heaps; I would like to have a first fault data capture facility (basically a log), which collects all the information it could get if something goes wrong (trap files etc.); I would like to see a program gracefully shut down in severe errors instead of simply core-dumping; I would like to have initial debug information via a trace, which the user can easily provide me with, if the problem is reproducable. I am used to that, and I think it is invaluable in the long run to get better code. Unfortunately, there is not much there that I found - I would admire the developers for their skills if there were no problems in the code. In my personal experience, high quality software should have a much higher focus. New features are nice, but they don't help anyone if things don't work in general. For example, for a long time I did not know and understand what a "buffer overflow" was, until I found a comment in some open source code that did a check to prevent such an overflow. It never occured to me to be so sloppy while programming. So is it just the user's fault? No, it is also the developer's fault in (a) providing the necessary infrastructure, (b) educating the user that any bug is bug that should and _will_ be fixed, and (c) having the self-discipline to do high-quality work, even if it takes longer. Programming is just engineering - not an art - and a major task of programming is error handling. p.s: I firmly believe that this point of view is independent of open vs. closed source. It is just that one can learn a lot (what one should and should not do) from open source because the source code is available. -- Knut Stolze