This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH: safe string copy and concetation

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 ...

> 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.

> 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.

> 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 ...

> 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)
	b) pasting some application-specific routine from one
	   program to another and constantly modifing it for
	   your own purpose


Always remember that you are unique.  Just like everyone else.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]