This is the mail archive of the libc-alpha@sources.redhat.com 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]
Other format: [Raw text]

Re: [open-source] Re: Wish for 2002


> Date: Thu, 03 Jan 2002 10:25:48 -0500
> From: David Wheeler <dwheeler@ida.org>
> 
> The OpenBSD developers, who have a lot of practical
> experience in securing applications,

The OpenBSD developers operate in a different environment from the GNU
developers.  They take a lot of code, much of it of poor quality, and
try to make it safer without necessarily having to understand it
thoroughly.  The goal is mainly to prevent certain things from
happening, not to improve the code quality or functionality.  In that
environment, strlcpy and strlcat can be useful.

GNU applications typically are developed under a different model, with
a set of maintainers who understand the code fairly well, and who try
to improve the code quality and functionality.  In that model, my
experience is that strlcpy and strlcat tend to be distractions: they
tend to make the code noticeably harder to maintain without adding
much safety.  That is why I recommend against their use in GNU code.


> It's faster, too (because the buffer size is often a compile-time
> constant)....  They force a fixed maximum length, which is sometimes
> desirable and sometimes isn't.

GNU applications typically avoid fixed buffer sizes.  The GNU coding
standards say:

   Avoid arbitrary limits on the length or number of _any_ data
   structure, including file names, lines, files, and symbols, by
   allocating all data structures dynamically.  In most Unix utilities,
   "long lines are silently truncated".  This is not acceptable in a GNU
   utility.

This may help to explain why strlcpy and strlcat are of relatively
little utility in most GNU code.


> strlcpy/strlcat are easier to use securely than the conventional
> strncpy/strncat

My impression is that GNU applications rarely use those functions either.
I think strcpy and strcat are more common.  (Obviously strcpy and
strcat must be used carefully, just as all these functions must be
used carefully.)


> Even if _you_ do not find them advantageous, a LOT
> of people who worry about application security _do_ find them
> advantageous.

They can easily include strlcpy/strlcat as source in their programs.
They have to do so anyway, if they want their code to be portable.
This is not a show-stopper problem for them.  It is not even a minor problem.
It is a trivial issue, and is one that they've addressed already.


The main dispute here is whether it should be extremely convenient to
use strlcpy/strlcat in applications that are not intended to be
portable outside a well-defined universe (namely, recent versions of
FreeBSD, OpenBSD, Solaris, and presumably GNU).

Another way to put the dispute is: should glibc promote the use of
these two controversial functions?  It is a legitimate question.  And
though the answer is "no" now, it may change to "yes" later --
certainly if these functions are standardized by POSIX.


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