Replace strlcpy() with memcpy() since the source buffer is not a string.
strlcpy() caught this anyway, but memcpy() usage is probably more valid.
==29766==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x562bc2e50420 in strlcpy /home/mbr/git/fwknop.git/common/strlcpy.c:61:3
#1 0x562bc2e25362 in process_packet /home/mbr/git/fwknop.git/server/process_packet.c:225:5
#2 0x7fa6173c9d57 (/lib64/libpcap.so.1+0x1fd57)
#3 0x562bc2e2456a in pcap_capture /home/mbr/git/fwknop.git/server/pcap_capture.c:227:15
#4 0x562bc2e13ef0 in main /home/mbr/git/fwknop.git/server/fwknopd.c:296:13
#5 0x7fa61643724a in __libc_start_main /usr/src/debug/glibc-2.27-74-g68c1bf8097/csu/../csu/libc-start.c:308:16
#6 0x562bc2d9dec9 in _start (/home/mbr/git/fwknop.git/server/.libs/fwknopd+0x1dec9)
Uninitialized value was created by a heap allocation
#0 0x562bc2da6c84 in malloc (/home/mbr/git/fwknop.git/server/.libs/fwknopd+0x26c84)
#1 0x7fa6173ca996 (/lib64/libpcap.so.1+0x20996)
SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/mbr/git/fwknop.git/common/strlcpy.c:61:3 in strlcpy
utils.c:217:13: warning: variable 'i' is incremented both in the loop header and in the loop
body [-Wfor-loop-analysis]
i++;
^
utils.c:213:34: note: incremented here
for (i=0; i<strlen(str); i++)
execvp() is (usually) equivalent to execvpe(), without enforcing any
change to the environment. However, unlike execvp(), execvpe() is not
standardized by POSIX, and may therefore not be available nor detected
when configuring the project (like on NetBSD).
No place could be found in fwknop to be using execvpe() and changing the
environment. Therefore it seems only logical (and safer) to use execvp()
instead.
This also updates the tests to reflect this change.
Characters should be casted as unsigned before use in functions from
<ctype.h>. Otherwise the compiler treats 8-bit characters (eg UTF-8) as
negative values (since it expects signed integers) and they no longer
match the comparison tables. Worse, the character 0xff gets interpreted
as -1 (like EOF). In turn, it helps to explicitly cast the result as a
signed integer, since this is what is expected. Characters in the range
0x80-0xff do keep their original values.
See the manual page for ctype(3) for more details (eg from NetBSD)
[server] Add MAX_FW_TIMEOUT to access.conf stanzas to allow a
maximum number of seconds for client-specified timeouts in SPA packets.
This fixes issue #226 which was spotted by Jeremiah Rothschild.
