RE: Standards for developing secure software

From: Witness (bmeyer67at_private)
Date: Thu Jan 23 2003 - 10:22:41 PST

  • Next message: Peter Gutmann: "RE: PGP scripting (reprise)"

    > <SNIP>
    > > Over the last few years programs have become larger and larger,
    > > partially because programmers have stopped worrying so much
    > about CPU
    > > and/or adding additional functionality, but more likely
    > some combination
    > > thereof.  Writing better programs (IMO) means writing the
    > program that
    > > is less CPU/memory intensive _and_ at the same time being
    > more secure.
    > > Why should we have to give up one for the other? I believe we can do
    > > them both.
    > </SNIP>
    > While I agree partially, we cannot forget the evolution of programming
    > languages as a catylist for ignoring CPU & memory.  As
    > languages become
    > more abstract there are fewer tools for manipulating memory
    > directly.  One
    > of the main selling points of high-level languages is the
    > fact that you DO
    > NOT have to worry about manually handling garbage collection or memory
    > manipulation.
    > Also, it is MUCH cheaper to upgrade the hardware that a
    > program is running
    > on, then to invest thousands of man-hours into making the program more
    > efficient.  Hardware tends to advance (in terms of power & speed)
    > relatively quickly, as compared to software.
    >
    > I do not mean to say that program efficiency should not be addressed,
    > because performance is *always* an issue.  But the point of these
    > higher-level languages is that programmers can focus on architecture,
    > security, and other things... rather than having to spend
    > time maximizing
    > the speed of a particular method.
    
    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.  And I for one don't think we should pay such a penalty
    for security. Instead, I think that programmers should do it right in
    the best language - that is one that provides the best speed/performance
    and functionality - for the scenerio and then do it right so as there is
    no need to incur costs like that of using Java.
    
    Just another $0.02,
    
    BRM
    



    This archive was generated by hypermail 2b30 : Thu Jan 23 2003 - 11:30:25 PST