Re: Implement C11 annex K?

[Rich Felker <dalias@libc.org>]

On Wed, Aug 13, 2014 at 04:43:58PM -0300, Adhemerval Zanella wrote:
> On 13-08-2014 16:23, David A. Wheeler wrote:
> > On Tue, 12 Aug 2014 19:48:17 -0400, dalias <dalias@libc.org> wrote:
> >> I'd much rather see strlcpy/strlcat added.
> > I'd be happy to have someone work to add strlcpy/strlcat, and
> > I'd be happy to focus on doing that *first*.
> > After all, strlcpy/strlcat are short, well-understood, and easy-to-use.
> > I see no need to put strlcpy/strlcat in a separate lib_s file, since they're short.
> > Annex K has other capabilities I'd like to see, and is a formal standard, but
> > staging work is fine.  I suspect that strlcpy/strlcat could help in implementing strcpy_s
> > (I'd have to check to make sure).
> >
> > So... would a high-quality strlcpy/strlcat patch be (FINALLY!) accepted?
> 
> From time to time it arises and there is small FAQ about it [1].  Bottom line: it is not
> consensus that the strlcpy/strlcat functions provides any more 'safety'.  You can check
> glibc alpha history and there are number of cases saying that it does not in fact, this is
> just and example [2]. 

I agree that these functions don't much to fix the underlying broken
and often insecure idioms of copying and concatenating strings, and I
don't like them and never recommend using them. But I still am in
favor of adding them to glibc, because lots of programs provide their
own when the system lacks them, and at least 75% of the reinvented
versions I've seen have critical bugs. So my main motivation for
wanting strlcpy/strlcat in glibc is just to prevent the buggy
application-provided ones from getting selected at configure time.

> I personally see compiler driver directives (like -D_FORTIFY_SOURCE or ASAN), runtime
> checks (like valgrind), or even higher level languages constructs (like std::string) to
> provide safety in a much more clean way. But I no expert in security...

-D_FORTIFY_SOURCE indeed tends to do a much better job, but it's a
"best effort" thing -- it's dependent on the compiler's analysis to
know object sizes, and if the compiler fails to do the necessary
analysis (e.g. at -O0) it fails open. Still I'd trust the compiler
more to get the actual object sizes right than I would trust the
programmer to get the args to the annex K functions right.

Rich