freebsd security - Jan 2016 - [Bug 193871] Certificates in /etc/ssl/certs not considered by pkg and fetch

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193871

--- Comment #6 from John W. O'Brien <john at saltant.com> ---
Created attachment 165049
  -->
https://bugs.freebsd.org/bugzilla/attachment.cgi?id=165049&action=edit
test for /etc/ssl/cert.pem existence to avoid masking SSL_CA_CERT_PATH

I have tested this and it works as intended. If you would like evidence, I
would need to boil down the test results to a form suitable for sharing.

In the course of testing, I realized that while the fallback to OpenSSL
defaults is good, the inconsistency between the semantics of the libfetch layer
of environment variables (SSL_CA_CERT_FILE, SSL_CA_CERT_PATH) and the defaults
in their absence and the libcrypto layer of environment variables
(SSL_CERT_FILE, SSL_CERT_DIR) and the defaults in their absence is not so good.
To wit, libfetch has a default file---two, in fact---but no default path,
whereas libcrypto has both, and the existence of either of the libfetch default
files will prevent the fallback to the OpenSSL defaults.

As I understand it, the reason that libfetch has a default to begin with,
rather than always using the OpenSSL default behavior, is mainly (solely?) to
allow the bundle from security/cs-nss-root to be picked up as the system
default, at least for libfetch and its consumers (like pkg), merely by virtue
of its installing a /usr/local/etc/ssl/cert.pem symlink, which is not a place
OpenSSL looks by default.

I don't have a recommendation at the moment, but when I do, it might be to
add
/usr/local/etc/certs as a path default for libfetch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.