Re: Theo chiming in on strlcpy

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Dec 21,  8:22pm, Marc Espie wrote:
} On Sat, Dec 21, 2013 at 07:10:46PM +0000, David Holland wrote:
} > On Sat, Dec 21, 2013 at 06:51:07PM +0100, Marc Espie wrote:
} >  > Oh, you can borrow from us (for the "recognizing bad code"), we've
} >  > been patching the compiler and the libc to warn about strcpy and
} >  > friends for years.  (the compiler, because otherwise, the built-ins
} >  > tend to vanish)
} > 
} > Right, because all uses of strcpy are bad. Yeah.
} 
} No, only about 99% of them.  There are many many developers out there,
} and most of them don't know how to write reasonably secure code.

     99% of statistics are made up (including this one).  :->

} Yeah, you're probably the 1% that uses strcpy correctly the first time.

     All my code either verify that it will fit the destination
string before hand, or use strn* and deals properly with potential
truncation.  Overruning a string isn't the only thing that causes
security problems.  Truncation is quite capable of doing it as
well.  At the very least, the app won't behave properly.  Once you
acknowlege this, strl* buys you nothing over strn* or just plain
str* with length calculation done before hand.

} But think about it.  Less gifted developers are going to use it incorrectly.
} Or go write impossible-to-audit messes.

     Those "less gifted developers" are just as likely to use strl*
incorrectly.

} I prefer having my code go 0.5% less fast, but not to have to spend hours
} auditing wacky wacky wacky string stuff.

     Using strl* isn't a miracle solution.  If you want to be sure,
you still have to audit it.

}-- End of excerpt from Marc Espie