When building with kerberos support (--with-kerberos), a few libraries
and flags need to be added to various parts of the build system. The
most reliable way to get those flags is through the krb5-config
program that ships with both major implementations of kerberos. The
PHP_SETUP_KERBEROS macro in acinclude.m4 attempts to detect
krb5-config, and use it.
However, there's a bug in that macro. The --with-kerberos parameter
accepts a directory where the kerberos libraries can be found. When a
directory is given, it is stored in the PHP_KERBEROS variable. The
following test,
if test "$PHP_KERBEROS" = "yes" && test -x "$KRB5_CONFIG"; then
thus fails whenever a directory is passed to --with-kerberos, since it
compares a directory name against the string "yes". This causes
krb5-config to go unused, and some unreliable fallback logic is
attempted instead. One consequence of this is that the Heimdal
kerberos implementation cannot be substituted for the MIT one, at
least when a directory is passed to --with-kerberos.
This commit reverses the logic and checks for "$PHP_KERBEROS" != "no".
To confirm that this fixes the issue, one can inspect the "-l" library
flags that get appended to the command-line. On a machine with Heimdal
and the unmodified acinclude.m4, running
./configure --with-openssl --with-kerberos=/usr
will log (for example) to config.log,
configure:18082: checking for krb5-config
configure:18101: found /usr/bin/krb5-config
configure:18114: result: /usr/bin/krb5-config
configure:18450: checking for RAND_egd
configure:18450: cc ... conftest.c ... -lgssapi_krb5 -lkrb5 ...
which are the library names for the MIT implementation. After patching
acinclude.m4 to negate the logic, the same command on the same machine
outputs (to config.log):
configure:18450: cc ... conftest.c -lgssapi -lheimntlm ...
These are the correct library names for the Heimdal implementation.
PHP-Bug: 73214
Simplify some unnecessarily complicated code. In particular the
length updates are unnecessary (length is only used at the very
start) and we're goto'ing around a bit too much.
The E_WARNING message from the PHP function lchown is passed
from the system function lchown. The error message returned
from lchown can be filesystem dependent.
Calling sqlite3_reset() when a result set object is freed can cause
undesired and maybe even hard to track interference with other result
sets. Furthermore, there is no need to call sqlite3_reset(), because
that is implicitly called on SQLite3Stmt::execute(), and users are
encouraged to explicitly call either SQLite3Result::finalize() or
SQLite3Stmt::reset() anyway.
As RETVAL_STRINGL_CHECK is already there, this one is needed for
completion. One place in ext/bz2 is missing that, so it will likely
be useful for other possible fixes.
