Re: Standards for developing secure software

From: Alex Russell (alexat_private)
Date: Thu Jan 23 2003 - 13:52:10 PST

  • Next message: Sandeep Giri: "Re: Can System() of Perl be bypassed?"

    On Thursday 23 January 2003 12:22, Witness wrote:
    > Here I must digress and cite the example of Java.  While it is certainly
    > the hll - and probably the one you are most thinking of - it is also the
    > language with the worst performance. While throwing more hardware
    > (memory/cpu) at it will speed it up and perhaps make the speed
    > differences between it and C or C++ less noticible, the difference will
    > still be there.
    
    so? If my choice is between something that's relatively safer yet slower and 
    something that's fast yet fragile, I'll take the lumbering tank any day. 
    You wouldn't drive a Formula 1 car to get groceries, it'd be stupid. As 
    soon as it hits a pothole, BOOM. So why do you think the programming 
    allegory is somehow a good idea?
    
    >  And I for one don't think we should pay such a penalty
    > for security. 
    
    then you don't really want security in any meaningful sense.
    
    Security is about playing the averages and managing risks (not about 
    eliminating every problem, although that would be nice). The less work 
    required of a programmer to do the right thing, the more trustable the 
    product. High level languages like Java and Python keep the programmer from 
    having to deal with _one class_ of problems (pushing your focus on problems 
    up the stack), and that's objectively good for your odds. Arguing against 
    reducing the complexity programmers have to deal with is like arguing that 
    we should only build airliners to go REALLY FAST. Pesky safety 
    equipment...just think how much more you could carry without it! Just so 
    long as you get there another 10% faster, right?  So what if they fall out 
    of the sky sometimes?
    
    It's a short-sighted argument that places speed over correctness. If it's 
    faster and broken, that just means that it breaks _faster_. Um yeah, I 
    think I'll pass on that.
    
    Additionally, you picked one of the worst performing high level languages 
    available as an example. If something other than portable assembler 
    (a.k.a., C) is really so anathema to you, I suggest you look around: large 
    portions of the programming world are moving to late-binding, interpreted 
    languages that allow programmers to do more with less and do it more 
    correctly. Entropy is always against us, no need to throw it a bone just 
    because you have some grudge against Moore's Law.
    
    -- 
    Alex Russell
    alexat_private
    alexat_private
    



    This archive was generated by hypermail 2b30 : Thu Jan 23 2003 - 13:16:55 PST