almg== Received: from ltc.des.dev (unknown [92.183.12.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4g9TK008DYzPXv; Wed, 06 May 2026 08:37:23 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 60E368EAC9; Wed, 06 May 2026 10:37:22 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Robert William Vesterman Cc: ports@freebsd.org, brnrd@freebsd.org Subject: Re: Apache24 and CVE-2026-23918 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> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Wed, 06 May 2026 10:37:22 +0200 Message-ID: <86pl39ue65.fsf@ltc.des.dev> List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-ports@freebsd.org Sender: owner-freebsd-ports@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Robert William Vesterman 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}) && !exist= s(${APU_LDAP}) IGNORE=3D LDAP and AUTHNZ_LDAP requires APR-util to have LDAP support b= uilt in.\ Please rebuild APR with LDAP support . endif . if ${PORT_OPTIONS:MSESSION_CRYPTO} && \ !(exists(${APU_CRYPTO_OPENSSL}) || exists(${APU_CRYPTO_NSS})) IGNORE=3D SESSION_CRYPTO requires APR-util to have crypto openssl suppo= rt built in.\ Please rebuild APR with crypto openssl support . endif . if exists(${APU_GDBM}) LIB_DEPENDS+=3Dlibgdbm.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 --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org