This is the mail archive of the libc-alpha@sourceware.org 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: Time to add strlcpy/strlcat FINALLY


On Wed, Aug 13, 2014 at 06:09:22PM -0700, Paul Eggert wrote:
> David A. Wheeler wrote:
> >The general consensus of people who have *studied*  how to develop secure software
> 
> Long ago, when I looked into the matter by examining the first few
> instances of strlcpy in OpenSSH (this was soon after they rewrote it
> to use strlcpy), the use of strlcpy did not fix any bugs and may
> have introduced one due to silent truncation.  This convinced me
> that strlcpy was not a good way to go for its intended application
> area.  And I'll bet my admittedly-brief study examined more
> empirical evidence than the cavalcade of experts you cited.
> 
> The argument is not strlcpy versus nothing.  It's strlcpy versus
> reasonable alternatives that take the same or less work.  These days
> the alternatives are better, so why refight this old battle?

What are the better alternatives? I'm not asking just to be
argumentative, but to get an idea of what you actually consider to be
an alternative to str[l]cpy/str[l]cat, and whether it's idiomatically
the same but fixed to be safe, or whether it requires switching to a
completely different C programming idiom that might have various pros
and cons.

My personal view is that strings should be constructed with memcpy or
snprintf (or equivalently asprintf, if you can deal with allocation
failures gracefully) as the rule, with deviations from the rule only
when they're well-justified. But I've seen plenty of programmers who
think you should always use a high-level string API, even in C; this
is another solution, but it definitely has its cons too. The one thing
I like about strlcpy/strlcat, despite that _I_ dislike the whole
copy/cat idiom, is that they allow people who are stuck on this idiom
(and unwilling to change) to make their code somewhat better at
checking for security-critical errors.

Rich


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