Determining certificate directory without including openssl

Jonathan Perkin <[email protected]>
Newsgroups gmane.os.netbsd.devel.packages
Message-ID <[email protected]>
I'm working on a new release for mktool.  Up until this point I've 
simply bundled the webpki-roots crate so that the mozilla rootcerts are 
bundled in the binary, and this continues to be the default for users 
like me who just 'cargo install mktool' and use that external binary for 
all fetching, etc, to avoid circular dependencies.

However I want to also support users who would like to use the system 
certificate store.  Unfortunately the pkgsrc support for this is a mess.

reqwest, the HTTP backend for mktool, uses rustls, a native Rust TLS 
implementation, and so I do not want to include OpenSSL.  However, I do 
want to determine where the certificate store is so that rustls can use 
it.

The way that builtin.mk files are written make this impossible to do 
without falling foul of pkglint, i.e. the "correct" way to do this and 
what some packages do is:

   CHECK_BUILTIN.foo=	yes
   .include foo/builtin.mk
   CHECK_BUILTIN.foo=	no

but the settings for SSLDIR, SSLCERTS, etc are all hidden behind 
CHECK_BUILTIN.openssl=no.

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.

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

It feels like my best option is to just ignore pkglint, include openssl 
builtin.mk directly, and then just pass SSL_CERT_DIR=${SSLCERTS}, but 
I'm not happy about breaking pkglint.

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.

-- 
Jonathan Perkin                    pkgsrc.smartos.org
Open Source Complete Cloud   www.tritondatacenter.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.