AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2010.07.08 16:25 "[Tiff] strlcpy vs strncpy", by Bob Friesenhahn
2010.07.08 18:03 "Re: [Tiff] strlcpy vs strncpy", by Lee Howard
2010.07.08 18:06 "Re: [Tiff] strlcpy vs strncpy", by Olivier Paquet
2010.07.11 17:36 "Re: [Tiff] strlcpy vs strncpy", by Edward Lam
2010.07.12 19:30 "[Tiff] strncpy in tiffcrop", by Richard Nolde
2010.07.12 20:31 "Re: [Tiff] strncpy in tiffcrop", by Edward Lam
2010.08.06 18:21 "Re: [Tiff] tiff4 on 32-bit Windows", by Toby Thain
2010.08.06 15:05 "[Tiff] tiff4 on 32-bit Windows", by John
2010.08.06 15:21 "Re: [Tiff] tiff4 on 32-bit Windows", by Bob Friesenhahn
2010.08.06 15:57 "Re: [Tiff] tiff4 on 32-bit Windows", by John
2010.08.06 16:24 "Re: [Tiff] tiff4 on 32-bit Windows", by Edward Lam
2010.08.06 16:51 "Re: [Tiff] tiff4 on 32-bit Windows", by Bob Friesenhahn
2010.08.06 16:38 "Re: [Tiff] tiff4 on 32-bit Windows", by Bob Friesenhahn
2010.08.09 12:59 "Re: [Tiff] tiff4 on 32-bit Windows", by John
2010.08.06 15:37 "Re: [Tiff] tiff4 on 32-bit Windows", by Olivier Paquet
2010.08.07 06:34 "[Tiff] tiffcp crashes on planar to strip conversion for < 8 bit", by Andreas Kleinert
2010.08.07 06:36 "Re: [Tiff] tiffcp crashes on tile to strip conversion for < 8 bit", by Andreas Kleinert
2010.08.15 04:45 "Re: [Tiff] tiffcp crashes on planar to strip conversion for < 8 bit", by Lee Howard
2010.07.10 11:04 "Re: [Tiff] strlcpy vs strncpy", by Albert Cahalan
2010.07.10 13:27 "Re: [Tiff] strlcpy vs strncpy", by Kevin Myers
2010.07.10 13:50 "Re: [Tiff] strlcpy vs strncpy", by Bob Friesenhahn
2010.07.11 07:34 "Re: [Tiff] strlcpy vs strncpy", by Albert Cahalan
2010.07.11 08:06 "Re: [Tiff] strlcpy vs strncpy", by Toby Thain
2010.07.11 14:35 "Re: [Tiff] strlcpy vs strncpy", by Bob Friesenhahn
2010.07.10 13:39 "Re: [Tiff] strlcpy vs strncpy", by Bob Friesenhahn
2010.07.11 08:18 "Re: [Tiff] strlcpy vs strncpy", by Albert Cahalan
2010.07.11 16:35 "Re: [Tiff] strlcpy vs strncpy", by Bob Friesenhahn
2010.07.12 17:34 "Re: [Tiff] strlcpy vs strncpy", by Dmitry V. Levin
2010.07.12 18:13 "Re: [Tiff] strlcpy vs strncpy", by Bob Friesenhahn
2010.08.02 19:47 "Re: [Tiff] BigTIFF Support in LibTiff", by Gajera Tejas
2010.08.02 19:25 "[Tiff] BigTIFF Support in LibTiff", by Gajera Tejas
2010.08.02 19:34 "Re: [Tiff] BigTIFF Support in LibTiff", by Bob Friesenhahn
2010.08.19 17:18 "[Tiff] tiff2ps page sizing options", by Richard Nolde
2010.08.23 04:54 "Re: [Tiff] tiff2ps page sizing options", by Lee Howard

2010.07.10 11:04 "Re: [Tiff] strlcpy vs strncpy", by Albert Cahalan

On Thu, Jul 8, 2010 at 12:25 PM, Bob Friesenhahn

<bfriesen@simple.dallas.tx.us> wrote:

I see that libtiff is using strncpy() as a safer strcpy() and strncat() as a safer strcat(). strncpy() does include  Unfortunately, a significant design flaw which causes it still to be insecure unless additional care is taken. problem occurs when the string to be  The copied exactly matches the buffer size, in which case the string will lack null termination.

That isn't a design flaw. You could argue that strncpy is a badly chosen name perhaps. The intended use is for character arrays, such as the one in wtmp and utmp files, which are not really strings in the normal C sense. Note how strncpy also zero-fills the remainder of the array; this behavior only makes sense for the intended purpose.

So strncpy isn't intended to do what you likely want, but strlcpy really does have a design flaw. It truncates the string. This can cause a security problem. To deal with that you'd need to check length and compare... but if you're going to do that then you've already written as much code as you'd need to write for doing things the standard and portable way: memcpy. Yep, that's right, memcpy is in <string.h> for a reason.

GraphicsMagick is using strlcpy() and strlcat() for secure string copies. will be happy to contribute versions that I wrote myself  I

Many decent programmers have botched reimplementations of various str* and mem* functions. You might need two hands to count the number of tries it took to get strncpy right in the Linux kernel. Sun shipped a libc that got these functions wrong when crossing a page boundry. Well-optimized code often has failures with bytes 0x7f, 0x80, and/or 0xff.

You can expect a modern compiler and C library to cooperate to provide a regression-tested implementation of str* and mem* functions that takes full advantage of the hardware. (aware of cache lines, aliasing issues, special-purpose instructions, etc.) I strongly suggest using what the platform provides rather than writing your own.