RE: PATCH: safe string copy and concetation

["MacGyver" <macgyver at tos dot net>]

> On Tue, Aug 08, 2000 at 01:25:20PM -0500, MacGyver wrote:
> > Actually, I agree with Ulrich and company on this.  Safe string
> handling, if
> > needed, should be implemented on an application by application
> basis.  You
> > can't rely on strlcat() and strlcpy() to exist on all platforms
> anyway, so
> > I'd end up implementing them in my package anyhow.
>
> 2 additional c files and one header in your tree ...
>

Clearly you missed the point.

> > I maintain a reasonably
> > popular/portable package -- ProFTPD -- and I implement my own
> safe string
> > handling functions precisely because:
> >
> > 1) Portability -- I know my version will work everywhere.
>
> Ok. argument. The OpenSSH people (for example) have implemented
> strlc{at,py}
> in their portable support tree.
>
> Thank's to autoconf and co we can use a native version, when aviable,
> and that's a good thing.
>

I don't care if they're there.  They work great for OpenSSH, but they're not
going to work great for ProFTPD.

> > 2) Peace of Mind -- I use my string functions only in
> particular cases, and
> > I know the consequences and side effects
> >                     of my implementation.
>
> "Everyone should write it's own libc because of knowing it better" -
> no, _that_ is ugly. That's just sourcebloat.
> Cut and pasteing secure functions is no alternative.
>

Writing your own utility functions in the face of an inadequate system
library, which is the case when you have to build something for a least
common denominator system, is not ugly.  It's portable.  Portability
inevitably adds code -- that's the nature of supporting the quirks of the
myriad of operating systems that exist today.

> > 3) Speed -- Because I know my specific requirements in my
> string functions,
> > they're optimized to suit my purposes.
>
> IMHO architectural optimizations can archive much better results ...
>

Not really much more than a good compiler, in the real world.  For my needs,
I'm not overly concerned with string performance to the degree say a
password cracker would be where there are assembler versions of strcmp for
all the CPUs in the world...

> > My conjecture is that otherwise, people will sloppily implement string
> > handling in their applications thinking they're safe from an
> entire class of
> > problems (namely buffer overruns), when in fact they are only
> masking the
> > true problem of bad code to begin with.
>
> What's more insecure ?
> 	a) having a well understood and documented function
> 	   in libc (or your support-library, which is based on
> 	   gnu oder bsd libc, I suppose)
> or
> 	b) pasting some application-specific routine from one
> 	   program to another and constantly modifing it for
> 	   your own purpose
>

Actually, they both can be insecure.  Bad code, poorly written or ugly code
as you put it, can be just as insecure.  And 'pasting some
application-specific routing from one program to another' implies that it's
somehow bad.  Lots of people cut and paste from sendmail because much of the
library code there meets your first criteria -- it's been around for ages,
and it's well understood.  That doesn't make it any more or less secure.

These religious wars rarely go anywhere however, and I suspect we'll just
agree to disagree here.

-Mac