Re: Determining certificate directory without including openssl

> Date: Thu, 29 Jan 2026 09:33:19 +0000
> From: Jonathan Perkin <[email protected]>
> 
> mk/ssl.mk, which I think was an attempt to consolidate this, is no good 
> because it defines the wrong directory, and has a warning at the top 
> that it shouldn't be included directly.

Yes, sorry, I didn't finish my attempt to consolidate this a year ago
and haven't picked it up again since then.

> Some packages just depend on mozilla-rootcerts and hardcode paths to 
> ${PREFIX}/share bundle, which is just wrong for users who use native 
> openssl.

Absolutely.

> Does anyone have a plan for cleaning this up?  Is there a reason why 
> mk/ssl.mk doesn't Just Work?  I think it will become more of an issue as 
> more Rust software moves to rustls.

My plan was to standardize pkgsrc variables SSLDIR, SSLCERTS,
SSLCERTBUNDLE as laid out in mk/ssl.mk comments so every package
consistently uses them (at least, for TLS server trust anchors; S/MIME
and other applications are a whole 'nother kettle of fish).

The trouble is that we have a lot of existing scenarios to consider:

1. Packages that use OpenSSL and:
   (a) OpenSSL (builtin or otherwise) uses system cert store, or
   (b) OpenSSL is from pkgsrc and uses pkgsrc cert store.

2. Packages that use GnuTLS, and
   (a) GnuTLS uses system cert store, or
   (b) GnuTLS is from pkgsrc and uses pkgsrc cert store.

3. Packages that use rustls, and...

Multiply this by:

  i. System _has_ a cert store (e.g., macOS, netbsd>=10).
 ii. System sort of has a cert store (e.g., netbsd<10 populated by
     hand or with mozilla-rootcerts-openssl, or various Linux).
iii. System _does not_ have a cert store (e.g., netbsd<10 out of the
     box, or various Linux, or maybe SmartOS -- not sure offhand).

And by:

alpha. Package understands how to use the system trust store
       (e.g., macOS keychain API).
 beta. Package does not understand how to use the system trust store,
       only how to read an openssl-hashed certs directory or a
       single-file cert bundle.

So we might end up with, e.g.:

- pkgsrc on macOS in /opt/pkg
- openssl uses /opt/pkg/etc/ssl/certs
- gnutls uses macOS cert store
- who knows what rustls or anything else uses

and if the operator has done any manual configuration in any of these
places, updating packages might break things.  Since I didn't have the
resources to go through and test the horrible set of paths like that,
I backed out the initial changes I started to make (see, e.g.,
security/gnutls/Makefile history).

The reason mk/ssl.mk says not to include it directly is so that
packages get the right cert store through the buildlink3 of the TLS
library they're using: openssl, gnutls, &c., whose builtin.mk would
include mk/ssl.mk as needed.  I probably did this because
disentangling the logic in security/openssl/builtin.mk was
complicated.

But I'm not attached to that approach, and mk/ssl.mk and mk/ssldir.mk
aren't used by anything right now after I backed out some initial
openssl and gnutls changes a year ago, so feel free to redo them.


I think what we should do is have two options, chosen by mk/ssl.mk
according to (a) system configuration and (b) mk.conf:

1. System has a cert store.
2. pkgsrc has a cert store.

User's mk.conf can configure the details (SSLCERTS, SSLCERTBUNDLE) if
they want; absent that, on systems with systemwide cert stores,
mk/ssl.mk should use those, and on systems without it, mk/ssl.mk
should use $PREFIX/etc/ssl/certs by default.  Every package should
consistently use whatever cert store mk/ssl.mk configures.

But I don't know how to handle issues like the macOS cert store which
doesn't manifest as SSLCERTS or SSLCERTBUNDLE.