Re: [PATCH] Implement strlcpy, strlcat [BZ #178]

[Paul Eggert <eggert at cs dot ucla dot edu>]

Two thoughts.

First, the September 2014 thread motivated strlcpy/strlcat in part by 
saying that Fedora has over 60 packages which define strlcpy/strlcat[1], 
the implication being that moving strlcpy/strlcat into glibc would fix 
more bugs than it would cause and would be worth the effort's cost. 
Skeptics like me can reasonably counter that the effort would likely 
just be security theater, in that it would not be of any real help but 
would merely exhibit activity in the security area, and possibly would 
even cause more problems than it fixes.

Data could help assuage skeptics' concerns. Although it's impossible to 
count bugs that are not discovered yet, we *do* now have twenty months' 
worth of data since September 2014. So: how many user-visible bugs 
and/or vulnerabilities have been discovered or reported in these 60-odd 
Fedora packages, bugs that would have been prevented by moving 
strlcpy/strlcat into a better-maintained library? New bugs cropping up 
would argue for change. Quietude would suggest that we leave things alone.


Second, the September 2014 thread said that another way to fortify 
strlcpy/strlcat, assuming we still want to do it, would be to use 
libbsd's strlcpy/strlcat implementation and add fortification to it. 
However, it was argued that this would be a Fedora-only effort and that 
libbsd contains functions like fgetln that are awkward. But isn't the 
point of libbsd to provide BSD functions that are awkward or 
questionable from the glibc point of view? And I don't see how work in 
libbsd would be Fedora-only, as other distributions like Debian also use 
libbsd, and whatever methods Fedora uses to merge strlcpy/strlcat into 
string.h would be methods that other distributions could use as well.

The Fedora bug report that corresponds to strlcpy/strlcat 
fortification[2] says that this is "Priority low Severity low", and from 
the above it appears that this is mainly a packaging problem instead of 
being a necessary addition to the core libc API.


[1] https://sourceware.org/ml/libc-alpha/2014-09/msg00357.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1032523