See also: last week's Letters page.

Letters to the editor

From:	 Gleef <gleef@ybten.net>
To:	 ripl@yahoo.com, letters@lwn.net
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 <mark.koek@stelvio.nl>
To:	 letters@lwn.net
Subject: Response to letter to LWN
Date:	 Fri, 02 Nov 2001 18:26:32 +0100
Cc:	 Rip Linton <ripl@yahoo.com>

Rip Linton <ripl@yahoo.com> 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:	 lwn@lwn.net
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:	 bryanh@giraffe-data.com (Bryan Henderson)
To:	 letters@lwn.net
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" <stolze@us.ibm.nospam.com>
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:	 letters@lwn.net

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