TIFF and LibTiff Mail List Archive


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.10 11:04 "Re: [Tiff] strlcpy vs strncpy", by Albert Cahalan
2010.07.12 17:34 "Re: [Tiff] strlcpy vs strncpy", by Dmitry V. Levin
2010.08.02 19:47 "Re: [Tiff] BigTIFF Support in LibTiff", by Gajera Tejas
2010.08.19 17:18 "[Tiff] tiff2ps page sizing options", by Richard Nolde

2010.07.08 16:25 "[Tiff] strlcpy vs strncpy", by Bob Friesenhahn

I see that libtiff is using strncpy() as a safer strcpy() and strncat() as a safer strcat(). Unfortunately, strncpy() does include a significant design flaw which causes it still to be insecure unless additional care is taken. The problem occurs when the string to be copied exactly matches the buffer size, in which case the string will lack null termination. The strlcpy() (and strlcat) functions avoid this glitch by always assuring null termination. The return value of strl*() are also much more useful since it is easy to test if the string was truncated (and by how much).

GraphicsMagick is using strlcpy() and strlcat() for secure string copies. I will be happy to contribute versions that I wrote myself for use in libtiff if libtiff choses to rely on these more secure functions. Libtiff should name the replacement functions differently in order to avoid any possible conflict/confusion with system provided versions, or versions from some dependent library or program.

Bob Friesenhahn,
GraphicsMagick Maintainer,