--- Begin Message ---
This happens because:
DEPENDS+= mozilla-rootcerts-[0-9]*:../../security/mozilla-rootcerts
...
CONFIGURE_ARGS+= --with-default-trust-store-file=${PREFIX}/share/mozilla-rootcerts/cacert.pem
This is wrong for two reasons:
1. it doesn't provide any way to override the decision, because
${PREFIX}/share/mozilla-rootcerts/cacert.pem is part of a package
rather than editable configuration; and
2. it doesn't respect OS-specific certificate stores, like
/etc/openssl/certs on NetBSD or /etc/pki/tls on various Linux
systems.
What this really should do is follow logic somewhat like what's in
security/openssl/builtin.mk for the OS's certificate store, in order
to determine that the correct path on NetBSD is
/etc/openssl/certs/ca-certificates.crt (as used by certctl(8) in
NetBSD>=10 and by the security/ca-certificates or
security/mozilla-rootcerts packages in older versions).
Unfortunately, security/openssl/builtin.mk is obviously specific to
OpenSSL -- and doesn't get the right path to the single-file bundle
used by GnuTLS (but it gets the right path to the hashed certificate
directory used by OpenSSL).
So I think we should create a new mk/ssl.mk or mk/ssltrustanchors.mk
or mk/sslcacerts.mk or something to place this logic properly, and use
it consistently both for GnuTLS and for OpenSSL -- and consider
pulling up either that or a more narrowly scoped stop-gap measure to
2024Q4, since this is a security risk when certctl(8) is supposed to
be able to promptly _distrust_ a CA in cases like the Digi-Notar
incident.
I found a handful of other packages that likely have the same issue,
with hard-coded references to share/mozilla-rootcerts:
lang/python27
security/botan3
security/p11-kit
security/qca2-qt5
security/qca2
sysutils/bsdec2-image-upload
--- End Message ---