openssl choice for www/apache24

[Havard Eidnes <he%NetBSD.org@localhost>]

Hi,

(didn't I write about this earlier?!?)

Since the apache web server exposes a few details about how it
was built (which version it is itself, which version of openssl
it is linked with, as well as versions of any extensions, on each
request...), I got alerted to the fact that we didn't run the
latest version of apache24 and also used a rather old version of
openssl in the follow-up of an external security scan.

I tend to run release versions of NetBSD itself (or maintenance
interim versions), which in practical terms means 9.3 or possibly
even older.

As distributed, the www/apache24 package will by default use the
in-tree openssl.  And since the in-tree openssl in 9.3 is 1.1.1k,
my installation got flagged.

Pkgsrc, on the other hand, with its quarterly releases had at the
time already moved to openssl version 1.1.1t, and this version
has fixes for the issues flagged by the security scan.
Explaining away the flagged issues would be quite a bit of work,
and would possibly also appear as "unconvincing".

So...  What is the proper way to influence a source build of
apache24 to use the pkgsrc openssl as opposed to the in-tree
openssl?

I beleive I made a couple of (failed) attempts at the time (my
memory is a bit hazy about what they were), and the traces I can
find is that I ended up by doing

RCS file: /cvsroot/pkgsrc/www/apache24/Makefile,v
retrieving revision 1.116
diff -u -p -r1.116 Makefile
--- Makefile    8 Mar 2023 08:52:02 -0000       1.116
+++ Makefile    20 May 2023 08:50:40 -0000
@@ -45,6 +45,7 @@ BUILDLINK_API_DEPENDS.apr+=   apr>=1.5.0
 BUILDLINK_API_DEPENDS.apr-util+=       apr-util>=1.5.3
 .include "../../devel/apr-util/buildlink3.mk"
 .include "../../devel/pcre2/buildlink3.mk"
+USE_BUILTIN.openssl=no
 .include "../../security/openssl/buildlink3.mk"
 .include "../../textproc/expat/buildlink3.mk"
 .include "../../mk/dlopen.buildlink3.mk"

in the www/apache24 Makefile, which looks quite heavy-handed.  Is
there a better way to do this, e.g. by asking for an openssl
version which is newer than the in-tree version?

I think the earlier attempts (ineffectually) tried to add to the
BUILDLINK_API_DEPENDS.openssl expression, hoping that would make
a difference (it didn't).

Regards,

- Håvard