Re: [SC-L] Genotypes and Phenotypes

2009-10-18 Thread Andy Steingruebl
On Mon, Oct 12, 2009 at 9:55 AM, Gunnar Peterson gun...@arctecgroup.net wrote:
 Its been awhile since there was a bugs vs flaws debate, so here is a snippet
 from Jaron Lanier
 A: No, no, they're not. What's the difference between a bug and a variation
 or an imperfection? If you think about it, if you make a small change to a
 program, it can result in an enormous change in what the program does. If
 nature worked that way, the universe would crash all the time. Certainly
 there wouldn't be any evolution or life. There's something about the way
 complexity builds up in nature so that if you have a small change, it
 results in sufficiently small results; it's possible to have incremental
 evolution. Right now, we have a little bit -- not total -- but a little bit
 of linearity in the connection between genotype and phenotype, if you want
 to speak in those terms. But in software, there's a chaotic relationship
 between the source code (the genotype) and the observed effects of
 programs -- what you might call the phenotype of a program.


Is this really true though?  A small change in libc doesn't change the
whole look and feel of a word processing program.  It looks exactly
the same, but maybe behaves very slightly differently over a small
range of inputs, etc.

And, while not being an expert in biology, I'm quite certain that
there are very minor mutations in certain key places that result in
complete system failure or almost entirely fatal diseases, conditions,
etc.

Is the complexity and expression of it really the key piece here?  Or
is it general resilience against failure, complexity spread out so
that the common enemies (transcription errors in one place) aren't
fatal.  The system is designed against different threat models.

-- 
Andy Steingruebl
stein...@gmail.com
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Genotypes and Phenotypes (Gunnar Peterson)

2009-10-17 Thread SC-L Reader Dave Aronson
Chris Wysopal cwyso...@veracode.com wrote:

 In certain cases like aircraft where the economic pain of failure
 is high you get DO-178B, Software Considerations in Airborne Systems and
 Equipment Certification.  For that type of software you might see the
 purchase of highly reliable libraries that have also met that certification.

Good point!  That's like how my former employer (BAE Systems) relied
for sales on those who NEEDED a data guard (or whatever) to be on a
platform that passed high levels of common criteria evaluation.  If it
weren't for that, similar software would have run just fine under
Linux (even without SE) or even Windows.

-Dave

--
Dave Aronson - Have Pun, Will Babble | Work: davearonson.com | /\ ASCII
-+ Play: davearonson.net | \/ Ribbon
Specialization is for insects. | Life: dare2xl.com | /\ Campaign
-Robert A. Heinlein  | Wife: nasjleti.net| EmailWeb
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Genotypes and Phenotypes (Gunnar Peterson)

2009-10-15 Thread Chris Wysopal

This seems to boil down to an economics problem.  Notice how quickly the bean 
counters showed up after the thread began with a discussion of bugs and 
complexity.  It is just too inexpensive to create new code and there isn't 
enough economic pain when it fails for anything to change for most software.  
In certain cases like aircraft where the economic pain of failure is high you 
get DO-178B, Software Considerations in Airborne Systems and Equipment 
Certification.  For that type of software you might see the purchase of highly 
reliable libraries that have also met that certification.

-Chris

From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On 
Behalf Of Andreas Saurwein Franci Gonçalves
Sent: Wednesday, October 14, 2009 9:49 AM
To: Secure Coding List
Subject: Re: [SC-L] Genotypes and Phenotypes (Gunnar Peterson)

2009/10/14 SC-L Reader Dave Aronson 
securecoding2d...@davearonson.commailto:securecoding2d...@davearonson.com
Andreas Saurwein Franci Gonçalves 
saurw...@gmail.commailto:saurw...@gmail.com wrote
(rearranged into  correct order):

 2009/10/13 Bobby Miller b.g.mil...@gmail.commailto:b.g.mil...@gmail.com

 The obvious difference is parts.  In manufacturing, things are assembled
 from well-known, well-specified, tested parts.  Hmmm

 Thats the idea of libraries. Well known, well specified, well tested parts.
 Well, whatever.
Ideally, yes.  However, programmers love to reinvent the wheel.  It's
MUCH easier, both to do and to get away with, in software than in
hardware... and often necessary.

Need a bolt of at least a given length and strength, less than a given
diameter?  There are standard thread sizes, and people make bolts of
most common threadings and lengths, for purchase at reasonable prices,
at places easily found, and you can be fairly certain that any given
one of them will do the job quite well.

Need a function for your program?  If it's as common as a bolt, it's
probably already built into the very language.  If it's nearly as
common, maybe there's a fairly standard library for it... and if
you're very lucky, it's not too buggy or brittle.  Otherwise, it's
probably going to be much cheaper (which is all your management
probably cares about) to just code the damn thing yourself, than to
research who makes such a thing, which ones there are, who says which
one is how reliable, which ones have licensing terms your company
finds palatable, and justifying your choice to management.  Lord help
you if it requires money, because then you have to justify it to a
higher degree, get the beancounters involved, budgetary authority from
possibly multiple layers of manglement, and spend the rest of your
days filling out purchase orders.

If you do wind up coding it yourself, is the company then going to
make that piece of functionality available to the world separately,
whether for profit or open source?  N times out of N+1, for very large
values of N, no way!

Will they at least make it available *internally*, so that *they*
don't have to reinvent the wheel *next* time?  Again, N times out of
N+1, for almost as large values of N, no.

-Dave

Exactly thats the point. Going a bit further, for every piece of  hardware 
engineering, there is almost always a legal, worldwide or at least national 
standard to follow. This is inexistent in software.

As long as anybody with at least one healthy finger is allowed to write and 
sell software, the current situation will not change.

Make software development an engineering discipline with all the rights and 
obligations of other engineering sciences.

No more coding without a license. Point. This would change the landscape of 
bits and bytes in a dramatic way. But it requires the support of the 
governments worldwide.

My 2 cents (me too would have to get back to college and study some more, 
although having 25+ years of software development experience)

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Genotypes and Phenotypes (Gunnar Peterson)

2009-10-14 Thread SC-L Reader Dave Aronson
Andreas Saurwein Franci Gonçalves saurw...@gmail.com wrote
(rearranged into  correct order):

 2009/10/13 Bobby Miller b.g.mil...@gmail.com

 The obvious difference is parts.  In manufacturing, things are assembled
 from well-known, well-specified, tested parts.  Hmmm

 Thats the idea of libraries. Well known, well specified, well tested parts.
 Well, whatever.

Ideally, yes.  However, programmers love to reinvent the wheel.  It's
MUCH easier, both to do and to get away with, in software than in
hardware... and often necessary.

Need a bolt of at least a given length and strength, less than a given
diameter?  There are standard thread sizes, and people make bolts of
most common threadings and lengths, for purchase at reasonable prices,
at places easily found, and you can be fairly certain that any given
one of them will do the job quite well.

Need a function for your program?  If it's as common as a bolt, it's
probably already built into the very language.  If it's nearly as
common, maybe there's a fairly standard library for it... and if
you're very lucky, it's not too buggy or brittle.  Otherwise, it's
probably going to be much cheaper (which is all your management
probably cares about) to just code the damn thing yourself, than to
research who makes such a thing, which ones there are, who says which
one is how reliable, which ones have licensing terms your company
finds palatable, and justifying your choice to management.  Lord help
you if it requires money, because then you have to justify it to a
higher degree, get the beancounters involved, budgetary authority from
possibly multiple layers of manglement, and spend the rest of your
days filling out purchase orders.

If you do wind up coding it yourself, is the company then going to
make that piece of functionality available to the world separately,
whether for profit or open source?  N times out of N+1, for very large
values of N, no way!

Will they at least make it available *internally*, so that *they*
don't have to reinvent the wheel *next* time?  Again, N times out of
N+1, for almost as large values of N, no.

-Dave

-- 
Dave Aronson, software engineer or trainer for hire.
Looking for job (or contract) in Washington DC area.
See http://davearonson.com/ for resume  other info.

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Genotypes and Phenotypes (Gunnar Peterson)

2009-10-14 Thread Andreas Saurwein Franci Gonçalves
2009/10/14 SC-L Reader Dave Aronson securecoding2d...@davearonson.com

 Andreas Saurwein Franci Gonçalves saurw...@gmail.com wrote
 (rearranged into  correct order):

  2009/10/13 Bobby Miller b.g.mil...@gmail.com
 
  The obvious difference is parts.  In manufacturing, things are
 assembled
  from well-known, well-specified, tested parts.  Hmmm

  Thats the idea of libraries. Well known, well specified, well tested
 parts.
  Well, whatever.

 Ideally, yes.  However, programmers love to reinvent the wheel.  It's
 MUCH easier, both to do and to get away with, in software than in
 hardware... and often necessary.

 Need a bolt of at least a given length and strength, less than a given
 diameter?  There are standard thread sizes, and people make bolts of
 most common threadings and lengths, for purchase at reasonable prices,
 at places easily found, and you can be fairly certain that any given
 one of them will do the job quite well.

 Need a function for your program?  If it's as common as a bolt, it's
 probably already built into the very language.  If it's nearly as
 common, maybe there's a fairly standard library for it... and if
 you're very lucky, it's not too buggy or brittle.  Otherwise, it's
 probably going to be much cheaper (which is all your management
 probably cares about) to just code the damn thing yourself, than to
 research who makes such a thing, which ones there are, who says which
 one is how reliable, which ones have licensing terms your company
 finds palatable, and justifying your choice to management.  Lord help
 you if it requires money, because then you have to justify it to a
 higher degree, get the beancounters involved, budgetary authority from
 possibly multiple layers of manglement, and spend the rest of your
 days filling out purchase orders.

 If you do wind up coding it yourself, is the company then going to
 make that piece of functionality available to the world separately,
 whether for profit or open source?  N times out of N+1, for very large
 values of N, no way!

 Will they at least make it available *internally*, so that *they*
 don't have to reinvent the wheel *next* time?  Again, N times out of
 N+1, for almost as large values of N, no.

 -Dave


Exactly thats the point. Going a bit further, for every piece of  hardware
engineering, there is almost always a legal, worldwide or at least national
standard to follow. This is inexistent in software.

As long as anybody with at least one healthy finger is allowed to write and
sell software, the current situation will not change.

Make software development an engineering discipline with all the rights
and obligations of other engineering sciences.

No more coding without a license. Point. This would change the landscape of
bits and bytes in a dramatic way. But it requires the support of the
governments worldwide.

My 2 cents (me too would have to get back to college and study some more,
although having 25+ years of software development experience)
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Genotypes and Phenotypes (Gunnar Peterson)

2009-10-13 Thread Bobby Miller
The obvious difference is parts.  In manufacturing, things are assembled
from well-known, well-specified, tested parts.  Hmmm


 ... If you look at other things
 that people build, like oil refineries, or commercial aircraft, we can
 deal with complexity much more effectively than we can with software.
 The problem with software is that we've never learned how to control
 the side effects of choices, which we call bugs.

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Genotypes and Phenotypes (Gunnar Peterson)

2009-10-13 Thread Andreas Saurwein Franci Gonçalves
Thats the idea of libraries. Well known, well specified, well tested parts.
Well, whatever.

2009/10/13 Bobby Miller b.g.mil...@gmail.com

 The obvious difference is parts.  In manufacturing, things are assembled
 from well-known, well-specified, tested parts.  Hmmm


 ... If you look at other things
 that people build, like oil refineries, or commercial aircraft, we can
 deal with complexity much more effectively than we can with software.
 The problem with software is that we've never learned how to control
 the side effects of choices, which we call bugs.


___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___