Use execvp() instead of execvpe()

[khorben]

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.

[mrash]

Question on this - for a call like 'execvpe(wget_argv[0], wget_argv, (char * const *)NULL);', the environment is explicitly being set to NULL so that it cannot contain any potentially malicious content. Is there an advantage to keeping this strategy? That is, does switching to execvp() imply that a non-NULL environment will influence how the exec'd binary will behave?

[khorben]

First, I misremembered that execvpe(file, argv, NULL) was equivalent to execvpe(file, argv, environ) and this is wrong. If we consider Linux, the environment is effectively set to be empty. However, the manual page says:

On Linux, argv and envp can
be specified as NULL. In both cases, this has the same effect as
specifying the argument as a pointer to a list containing a single null
pointer. Do not take advantage of this misfeature! It is nonstandard
and nonportable: on most other UNIX systems doing this will result in
an error (EFAULT).

(emphasis originally there)

Without even considering this, I do not see how the environment can be malicious. Commands are started either by the server or the client, but in both cases the user controls the environment. If it is already corrupted somehow, I would say there is a different, bigger problem, independently of fwknop. Actually, it might also be considered buggy to clear the environment free from environment variables like http_proxy and the like in the case of wget for instance.

[mrash]

Ok, that is a good argument. Merging.