Re: If glibc had a logo what would it be?

[Rich Felker <dalias at aerifal dot cx>]

On Sun, Dec 09, 2012 at 12:45:34AM -0600, William Pitcock wrote:
> > Post a patch then :).  Also see the FAQ which describe why they are
> > not a good idea and an even better alternative:
> > http://sourceware.org/glibc/wiki/FAQ#Why_no_strlcpy_.2BAC8_strlcat.3F
> 
> Why would I bother posting a patch when you have already attached a
> talking point to it to explain why it is in the opinion of the GLIBC
> maintainers a bad set of functions?

Exactly.

> While I agree that FORTIFY is a better approach (or some other
> mechanism which semantically tests for correctness at compile-time),

FORTIFY and strlcpy serve completely orthogonal purposes. The former
causes incorrect code to error at compile time or abort at runtime.
The latter facilitates correct code handling an exceptional condition
(input too big to fit in a buffer whose size is not variable based on
the input). It's not the best way to handle the situation, but a lot
of things libc lets you do are not the best way to handle the
situations they go with.

> this does not solve the problem that thousands of apps have to ship
> strlcpy() stubs just to work around the fact that the GLIBC
> maintainers will not include support for them.  Infact, you have gone
> to more work writing the FAQ entry than it would be to just integrate
> the functions into GLIBC.

The fact that it's a FAQ suggests to me that, unless there's some
_harm_ that will come from adding strl*, they should just be added.

The main possible harm I can think of is the incessant addition of asm
variants for string functions, usually with subtle corner-case bugs
since the folks who like asm are usually not the same people who like
rock-solid robustness in all corner cases. If these functions are
added, I would support a no-asm policy for them, so that we don't have
to worry about security being broken because someone though adding a
new SSE9 variant would be "cool"...

> Have you considered the security implications of applications using a
> broken strlcpy() stub?  Do you not agree that adding the functionality
> to GLIBC would cut down on broken stubs being distributed? (There is a
> strlcpy() in Linux, which does not have equivalent behavior to the BSD
> one.  Specifically, it's broken.)

If you're talking about Linux kernelspace, having it in glibc would
not improve that situation. In general, I see no fundamental reason
kernelspace functions have to have the exact same semantics as
userspace ones by the same names (at present, lots don't), but it sure
would make things less confusing if they were the same...

Rich