Simon Josefsson wrote:
Howard Chuhyc@symas.com writes:
I strongly recommend that GnuTLS not be used. All of its APIs would need to be overhauled to correct its flaws and it's clear that the developers there are too naive and inexperienced to even understand that it's broken.
I looked at the X.509 API's (x509.h) and I couldn't find any other that didn't take buffer length arguments. I didn't look carefully though.
There is 1 (one) use of 'strcat' in the X.509 code, and it looks correct to me. There was 20 uses of 'strlen' in the X.509 code, and I went over the first matches but when they looked correct I didn't look further. (For reference, the X.509 code size is around 21000 lines of code.)
If you can give more details, that would be appreciated.
And while we're at it, x509/x509.c uses memmem() which on my system says: man memmem:
CONFORMING TO This function is a GNU extension.
BUGS This function was broken in Linux libraries up to and including libc 5.0.9; there the `needle' and `haystack' arguments were interchanged, and a pointer to the end of the first occurrence of needle was returned. Since libc 5.0.9 is still widely used, this is a dan‐ gerous function to use. Both old and new libc's have the bug that if needle is empty haystack-1 (instead of haystack) is returned. And glibc 2.0 makes it worse, and returns a pointer to the last byte of `haystack'. This is fixed in glibc 2.1.
While I would expect that most Linux sites are running something newer than glibc 2.1 these days, it's still a poor choice to use a GNU-specific library function in portable code. Not all the world runs Linux. I've been involved with the FSF since 1988 and I still have to accept the fact that the GNU way isn't the only way.
Howard Chu hyc@symas.com writes:
Simon Josefsson wrote:
Howard Chuhyc@symas.com writes:
I strongly recommend that GnuTLS not be used. All of its APIs would need to be overhauled to correct its flaws and it's clear that the developers there are too naive and inexperienced to even understand that it's broken.
I looked at the X.509 API's (x509.h) and I couldn't find any other that didn't take buffer length arguments. I didn't look carefully though.
There is 1 (one) use of 'strcat' in the X.509 code, and it looks correct to me. There was 20 uses of 'strlen' in the X.509 code, and I went over the first matches but when they looked correct I didn't look further. (For reference, the X.509 code size is around 21000 lines of code.)
If you can give more details, that would be appreciated.
And while we're at it, x509/x509.c uses memmem() which on my system says: man memmem:
CONFORMING TO This function is a GNU extension.
BUGS This function was broken in Linux libraries up to and including libc 5.0.9; there the `needle' and `haystack' arguments were interchanged, and a pointer to the end of the first occurrence of needle was returned. Since libc 5.0.9 is still widely used, this is a dan‐ gerous function to use. Both old and new libc's have the bug that if needle is empty haystack-1 (instead of haystack) is returned. And glibc 2.0 makes it worse, and returns a pointer to the last byte of `haystack'. This is fixed in glibc 2.1.
While I would expect that most Linux sites are running something newer than glibc 2.1 these days, it's still a poor choice to use a GNU-specific library function in portable code. Not all the world runs Linux. I've been involved with the FSF since 1988 and I still have to accept the fact that the GNU way isn't the only way.
GnuTLS is intended to work best on GNU systems, so we use extensions like memmem. To be compatible, GnuTLS uses gnulib, which contains a memmem replacement for those systems that doesn't have memmem, or where it is buggy. See lgl/m4/memmem.m4 for the autoconf test, and lgl/memmem.c for the replacement code, which is used on all non-GNU platforms.
The use of memmem was actually introduced a few years ago (by me) to clean up the earlier ad-hoc code that used strnstr instead (which, incidentally wouldn't handle embedded NUL's). Glibc 2.1 was released in -99, before the GnuTLS project was even started.
/Simon