Is finding security holes a good idea?

Steven M. Bellovin smb at research.att.com
Mon Jun 14 17:10:48 EDT 2004


In message <40CDB9BC.6000005 at algroup.co.uk>, Ben Laurie writes:

>
>What you _may_ have shown is that there's an infinite number of bugs in 
>any particularly piece of s/w. I find that hard to believe, too :-)
>

Or rather, that the patch process introduces new bugs.  Let me quote 
from Fred Brooks' "Mythical Man-Month", Chapter 11:

	The fundamental problem with program administration is that fixing
	a defect has a substantial (20-50 percent) chance of introducing
	another.  So the whole process is two steps forward and one step
	back.

	Why arene't defects fixed more cleanly?  First, even a subtle
	defect shows itself as a local failure of some kind.  In fact it
	often has system-wide ramifications, usually nonobvious.  Any
	attempt to fix it with minimum effort will repair the local and
	obvious, but unless the structure is pure or the documentation
	very fine, the far-reaching effects of the repair will be
	overlooked.  Second, the repairer is usually not the man who wrote
	the code, and often he is a junior programmer or trainee.

	As a consequence of the introduction of new bugs, program
	maintenance requires far more system testing per statement written
	than any other programming.

	...

	Lehman and Belady have studied the history of successive release
	in a large operating system.  They find that the total number of
	modules increases linearly with release number, but that the
	number of modules affected increases exponentially with release
	number.  All repairs tend to destroy the structure, to increase
	the entropy and disorder of the system.  Less and less effort is
	spent on fixing original design flaws; more and more is spent on
	fixing flaws introduced by earlier fixes.  As time passes, the
	system becomes less and less well-ordered.  Sooner or later the
	fixing ceases to gain any ground.  Each forward step is matched by
	a backward one.

Etc.  In other words, though the original code may not have had an
infinite number of bugs, the code over time will produce an infinite
series....

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list