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

[Florian Weimer <fweimer at redhat dot com>]

On 09/15/2014 06:56 PM, David Miller wrote:
>> But really, it'd be better to keep leaving it out.  It's just a mess.
> 
> This is really confusing.
> 
> If glibc never had strlcpy before, it's an oxymoron to say it shouldn't
> be used for new code because that's the only possible usage of it.
> 
> If people are just going to start using the glibc copy when available
> instead of their own home-grown tree local implementation, which seems
> to be the only remaining "suggested" usage, I say that's bogus too.
> 
> So we're providing an interface for people using strlcpy, but at the
> same time we don't want people to use strlcpy and rather have them
> use "something else."
> 
> Our actions are going to encourage them to continue using strlcpy.

We could point out that using strlcpy with statically sized buffers is
against the GNU Coding Standards, which recommend dynamic, on-demand
buffer allocation.

Here's some more background why I'm proposing this.  Fedora has over 60
source packages which compile to binary packages which define strlcpy or
strlcat.  Many of these packages will not go away, ever.  Only a subset
of the software has a strong (Open)BSD affinity.

The implementations I have seen bypass fortify protection.  We could
make libbsd the canonical implementation and bring it up to current
glibc standards, but it would be a Fedora-only effort with limited
benefit.  And I'd rather wish libbsd would go away (the fgetln
implementation is sufficient reason for that).

-- 
Florian Weimer / Red Hat Product Security