Ulf, can we end this debate here? We are both on the same side.
Ulf Lamping wrote:
> Andrew Hood wrote:
>
>> So include it (unless you have a problem with the BSD-style license),
>> and let configure decide if it needs to be compiled. Quote:
>>
>> Availability
>>
>> The source code for strlcpy() and strlcat() is available free of charge
>> and under a BSD-style license as part of the OpenBSD operating system.
>> You may also download the code and its associated manual pages via
>> anonymous ftp from ftp.openbsd.org in the directory
>> /pub/OpenBSD/src/lib/libc/string. The source code for strlcpy() and
>> strlcat() is in strlcpy.c and strlcat.c. The documentation (which uses
>> the tmac.doc troff macros) may be found in strlcpy.3.
>>
>>
> Ok, some background here.
>
> I think that using strcpy (and strcat which is "basically" the same
> thing in this regard) is commonly known to be often causing security
> problems.
>
> If you have a look how strcpy is often used inside Ethereal, you'll
> notice that people tend to re implement sprintf in some way. Doing this
> is just another way to invent new security problems.
>
> Realizing this, it comes to the point of forcing (unskilled) developers
> to use secure functions. The easiest way to do this is to forbid the
> usage of functions known to cause trouble. And it's not only the
> function usage making trouble, but also the surroundings of that function.
>
> Using a stack buffer to work with strcpy (and alike) is a common cause
> of security problems ...
I am well aware of the issues with using any of the unconstrained copy
functions. I never use them myself, and usually replace them when
modifying existing code.
I did a quick scan of source code on my system and found all the
following included strlcpy in case the target system did not have it:
X11
dictd
inn
labrea
libdnet
net-snmp
openssh
snort
tcpdump
Why shouldn't Ethereal join them?
--
There's no point in being grown up if you can't be childish sometimes.
-- Dr. Who
