USES= caroot

[adamw]

Summary

This should be a no-op on 12.2+, and should bring in ca_root_nss on everything below it. All ports depending on ca_root_nss should switch to USES=caroot.

[kevans]

I have a complementary patch that also starts using USES=caroot on all consumers, but I'll need to rebase it

[adamw]

In D31487#709659, @kevans wrote:

I have a complementary patch that also starts using USES=caroot on all consumers, but I'll need to rebase it

In retrospect, I should have checked with you first before uploading this. Does your patch include the Uses/caroot.mk as well?

[kevans]

In D31487#709663, @adamw wrote:

In D31487#709659, @kevans wrote:

I have a complementary patch that also starts using USES=caroot on all consumers, but I'll need to rebase it

In retrospect, I should have checked with you first before uploading this. Does your patch include the Uses/caroot.mk as well?

No worries. :-)

It does, but an inferior version of Uses/caroot.mk with loads of complexity that the rest of the patch didn't end up using. I'm going to go ahead and rebase my patch to the latest main with this version of USES=caroot, and I'll post it as a successor once I'm sure I've caught the remaining instances.

[michaelo]

Question: Is this worth the effort given that 11.4 will be EOL in 1,5 months and all supported versions will have the root trust store installed by default?

[adamw]

In D31487#710103, @1983-01-06_gmx.net wrote:

Question: Is this worth the effort given that 11.4 will be EOL in 1,5 months and all supported versions will have the root trust store installed by default?

You know, that's a good point. In October we can just remove ca_root_nss hard deps, so it's probably not worth the churn.

[kevans]

So we really just need to decide what to do with CA_BUNDLE stuff, or understand what those ports do without it or if they can use the hashed store instead.

[michaelo]

In D31487#710272, @kevans wrote:

So we really just need to decide what to do with CA_BUNDLE stuff, or understand what those ports do without it or if they can use the hashed store instead.

I will give you an answer you are not going to like:

1. Fix base: search for all occurencies of these methods and make sure that by default only the default store is used unless configured otherwise by the admin/user and not the way around like libfetch does:

$ grep -r --include='*.c*' -e SSL_CTX_set_default_verify_paths -e SSL_CTX_set_default_verify_dir -e SSL_CTX_set_default_verify_file -e SSL_CTX_load_verify_locations .
./contrib/libevent/sample/https-client.c:       if (1 != SSL_CTX_load_verify_locations(ssl_ctx, crt, NULL)) {
./contrib/libevent/sample/https-client.c:               err_openssl("SSL_CTX_load_verify_locations");
./contrib/openbsm/bin/auditdistd/proto_tls.c:   //SSL_CTX_load_verify_locations(sslctx, cacerts_file, NULL);
./contrib/sendmail/src/tls.c:           if ((r = SSL_CTX_load_verify_locations(*ctx, cacertfile,
./contrib/unbound/daemon/remote.c:      if(!SSL_CTX_load_verify_locations(rc->ctx, s_cert, NULL)) {
./contrib/unbound/services/outside_network.c:            * SSL_CTX_set_default_verify_paths */
./contrib/unbound/smallapp/unbound-control.c:   if (SSL_CTX_load_verify_locations(ctx, s_cert, NULL) != 1)
./contrib/unbound/util/net_help.c:              if(!SSL_CTX_load_verify_locations(ctx, verifypem, NULL)) {
./contrib/unbound/util/net_help.c:                      if(!SSL_CTX_load_verify_locations(ctx, verifypem, NULL)) {
./contrib/wpa/src/crypto/tls_openssl.c:         if (SSL_CTX_load_verify_locations(ssl_ctx, ca_cert, ca_path) !=
./contrib/wpa/src/crypto/tls_openssl.c:         if (SSL_CTX_load_verify_locations(ssl_ctx, ca_cert, NULL) != 1)
./contrib/wpa/src/crypto/tls_wolfssl.c:         if (wolfSSL_CTX_load_verify_locations(ctx, ca_cert, ca_path) !=
./contrib/wpa/src/crypto/tls_wolfssl.c:         if (wolfSSL_CTX_load_verify_locations(ctx, ca_cert, NULL) != 1)
./lib/libfetch/common.c:                        SSL_CTX_load_verify_locations(ctx, ca_cert_file,
./lib/libfetch/common.c:                        SSL_CTX_set_default_verify_paths(ctx);

2. Fix https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253060 and https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256902. The libfetch bug is embarrassing.
3. Analyze why OpenSSL from ports has a different OPENSSLDIR in contrast to LibreSSL: /usr/localopenssl vs /usr/local/etc/ssl. I would consider to consolidate to the latter in consistency with /etc/ssl
4. Open all ports with ca_root_nss dependency source code and search for the OpenSSL functions from above and make sure that they call SSL_CTX_set_default_verify_paths()/SSL_CTX_set_default_verify_dir() if not, report upstream to do that and provide a downstream patch with the port maintainer meanwhile.
5. Talk to koobs@ to fix https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230414 finally
6. If a port uses a crypto framework which *cannot* make use of /etc/ssl/certs (hashed dir), but requires a concatenated file of base64 encoded certs (RFC 7468) in, say /etc/ssl/cert.pem (default for OpenSSL in base) or somewhere else, modify certctl(8) and make it concat from /etc/ssl/certs by default. Make is configure by NO_CERT_BUNDLE if admin explicitly wants to disable it for the system. Make those ports to use it by default by some means.
7. Consider what needs to be done if make.conf contains ssl=openssl/libressl/libressl-devel, i..e, not base. How is /etc/ssl/certs supposed to work? It obviously can't.
8. Fix this for Java: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229329. I can help out on this. I have fixed this for us internally (Siemens Dynamowerk) with a custom port and can assist to make this happen on a step-by-step basis. Willing to provide my Java source if Greg Lewis is willing to with me on this.

List may be even incomplete...

OpenSSL reference: https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_set_default_verify_paths.html

That's it for now. Now hate me ;-)

[michaelo]

Is there anything I can do to make progress?

[kevans]

In D31487#720855, @1983-01-06_gmx.net wrote:

Is there anything I can do to make progress?

Hey, sorry. :-( I'm hoping I can find the energy to put into CA stuff going into the new year.

[michaelo]

In D31487#758826, @kevans wrote:

In D31487#720855, @1983-01-06_gmx.net wrote:

Is there anything I can do to make progress?

Hey, sorry. :-( I'm hoping I can find the energy to put into CA stuff going into the new year.

No issue, let me know when I can help. Maybe meetup on IRC or similar.