ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Sergey Lentsov                       2:4615/71.10   08 Nov 2001  17:11:35
 To : All
 Subject : URL: http://www.lwn.net/2001/1108/letters.php3
 -------------------------------------------------------------------------------- 
 

    [1][LWN Logo] 
    
                                [2]Click Here 
    [LWN.net]
    
    Sections:
     [3]Main page
     [4]Security
     [5]Kernel
     [6]Distributions
     [7]Development
     [8]Commerce
     [9]Linux in the news
     [10]Announcements
     [11]Linux History
     Letters
    [12]All in one big page
    
    See also: [13]last week's Letters page.
    
 Letters to the editor
 
    Letters to the editor should be sent to [14]letters@lwn.net.
    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 <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:
    [15]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
 
    
    
                                                                          
    
    [16]Eklektix, Inc. Linux powered! Copyright Л 2001 [17]Eklektix, Inc.,
    all rights reserved
    Linux (R) is a registered trademark of Linus Torvalds
 
 References
 
    1. http://lwn.net/
    2. http://ads.tucows.com/click.ng/pageid=pageid=132-000-001-001
    3. http://lwn.net/2001/1108/
    4. http://lwn.net/2001/1108/security.php3
    5. http://lwn.net/2001/1108/kernel.php3
    6. http://lwn.net/2001/1108/dists.php3
    7. http://lwn.net/2001/1108/devel.php3
    8. http://lwn.net/2001/1108/commerce.php3
    9. http://lwn.net/2001/1108/press.php3
   10. http://lwn.net/2001/1108/announce.php3
   11. http://lwn.net/2001/1108/history.php3
   12. http://lwn.net/2001/1108/bigpage.php3
   13. http://lwn.net/2001/1101/letters.php3
   14. mailto:letters@lwn.net
   15. http://eserver.org/thoreau/civil.html
   16. http://www.eklektix.com/
   17. http://www.eklektix.com/
 
 --- ifmail v.2.14.os7-aks1
  * Origin: Unknown (2:4615/71.10@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор