Date: Wed, 06 May 2026 10:37:22 +0200 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@FreeBSD.org> To: Robert William Vesterman <bob@vesterman.com> Cc: ports@freebsd.org, brnrd@freebsd.org Subject: Re: Apache24 and CVE-2026-23918 Message-ID: <86pl39ue65.fsf@ltc.des.dev> In-Reply-To: <8799bbb8-51e4-4d34-8d11-8b8647ce0052@vesterman.com> (Robert William Vesterman's message of "Tue, 5 May 2026 20:56:42 -0400") References: <01352fca242dd5f3af2bf60b3855faa1@angelhess.com> <8799bbb8-51e4-4d34-8d11-8b8647ce0052@vesterman.com>
index | next in thread | previous in thread | raw e-mail
Robert William Vesterman <bob@vesterman.com> writes:
> (9) Somebody then noticed that the FreeBSD Porters' Handbook
> specifically describes the sort of change that was made to the Apache
> makefile as "wrong", and (if made) will cause problems exactly like
> were happening here. But...
Correct. I'm surprised nobody else has raised this issue, considering
how load-bearing www/apache24 is. And I find Bernard's behavior in the
ticket very disappointing.
The problem is this section of www/apache24/Makefile:
# Check for APR-util module exists
.if exists(${APU_CONFIG})
. if (${PORT_OPTIONS:MLDAP} || ${PORT_OPTIONS:MAUTHNZ_LDAP}) && !exists(${APU_LDAP})
IGNORE= LDAP and AUTHNZ_LDAP requires APR-util to have LDAP support built in.\
Please rebuild APR with LDAP support
. endif
. if ${PORT_OPTIONS:MSESSION_CRYPTO} && \
!(exists(${APU_CRYPTO_OPENSSL}) || exists(${APU_CRYPTO_NSS}))
IGNORE= SESSION_CRYPTO requires APR-util to have crypto openssl support built in.\
Please rebuild APR with crypto openssl support
. endif
. if exists(${APU_GDBM})
LIB_DEPENDS+=libgdbm.so:databases/gdbm
. endif
.endif # exists APU_CONFIG
The outermost check may seem pointless since www/apache24 requires
devel/apr1, and devel/apr1 always installs apu-1-config, but in fact it
is there to prevent the inner checks from being evaluated before the
dependencies have been installed (which is a big red flag...)
The second and third checks (APU_CRYPTO_OPENSSL and APU_CRYPTO_NSS) are
a workaround for the fact that we have no way of recording that we
require a particular dependency to have been built with particular
options. This particular case could be solved with subports if we had
them, or it could be solved by creating individual ports for
apr_crypto_openssl and apr_crypto_nss.
The third check is also a workaround for depending on a particular
option and could be solved in a similar manner. But unlike the crypto
checks, it does not prevent building the port if devel/apr1 was built
without the GDBM option. It does however cause www/apache24 to report a
different dependency list before and after dependencies have been
installed, which is what breaks synth. It does not break poudriere, but
I would argue that that's a flaw in poudriere.
DES
--
Dag-Erling Smørgrav - des@FreeBSD.org
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86pl39ue65.fsf>