Nikolay Kolev reported a build issue on Mac OS X 10.9 (Mavericks) where fwknop
copies of strlcpy() and strlcat() functions were conflicting with those that ship
with OS X 10.9.
The solution was to add a configure.ac check for strlcat() and strlcpy() and
wrap "#if !HAVE_..." checks around those functions.
A portion of the build errors looked like this:
/Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive
Making all in lib
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I ../common -g -O2 -Wall -Wformat -Wformat-security -fstack-protector-all -fstack-protector -fPIE -D_FORTIFY_SOURCE=2 -MT base64.lo -MD -MP -MF .deps/base64.Tpo -c -o base64.lo base64.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I ../common -g -O2 -Wall -Wformat -Wformat-security -fstack-protector-all -fstack-protector -D_FORTIFY_SOURCE=2 -MT base64.lo -MD -MP -MF .deps/base64.Tpo -c base64.c -fno-common -DPIC -o .libs/base64.o
In file included from base64.c:34:
In file included from ./fko_common.h:149:
./fko_util.h:56:9: error: expected parameter declarator
size_t strlcat(char *dst, const char *src, size_t siz);
^
/usr/include/secure/_string.h:111:44: note: expanded from macro 'strlcat'
__builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))
^
/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'
#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)
^
When --enable-valgrind is used, this commit adds support for running the
perl FKO built-in tests (in the t/ directory) under the CPAN
Test::Valgrind module. A check is performed to see whether
Test::Valgrind is install before attempting to use it. Any 'fko_'
function that shows up under the test output is flagged and causes the
test-suite test to fail.
This commit adds an AppArmor policy that is known to work in Debian and Ubuntu
systems. The original version of this policy was contributed by Radostan Riedel
to the fwknop mailing list.
This commit fixes a crash if the replay digest init() routine fails - fwknopd
attempted to make use of replay tracking anyway. The crash was discovered
during testing fwknopd with an AppArmor enforce policy deployed. The
following stack trace shows the crash (taken before the previous static
function commit):
Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
31 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory.
(gdb) where
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
#1 0x00007f59cabd8b26 in add_replay_file_cache (opts=opts@entry=0x7fff3eaa0bb0, digest=digest@entry=0x0) at replay_cache.c:516
#2 0x00007f59cabd8cf5 in add_replay (opts=opts@entry=0x7fff3eaa0bb0, digest=digest@entry=0x0) at replay_cache.c:472
#3 0x00007f59cabd62eb in incoming_spa (opts=0x7fff3eaa0bb0) at incoming_spa.c:536
#4 0x00007f59ca56164e in ?? () from /usr/lib/x86_64-linux-gnu/libpcap.so.0.8
#5 0x00007f59cabd7175 in pcap_capture (opts=opts@entry=0x7fff3eaa0bb0) at pcap_capture.c:269
#6 0x00007f59cabd3d4d in main (argc=5, argv=0x7fff3eaa1458) at fwknopd.c:314
[libfko] (Hank Leininger) Contributed a patch to greatly extend libfko
error code descriptions at various places in order to give much better
information on what certain error conditions mean. Closes#98.
