Hi, Due to code audits and reviews the topic of default bundle location handling was brought up. The bundles are less interesting today with certctl but since the option is still the default I want to straighten out the behaviour. * Treat /usr/local/openssl/cert.pem the same as /etc/ssl/cert.pem under ETCSYMLINK use and avoid its creation when the option is off. * Remove /usr/local/openssl/cert.pem.sample to match the behaviour of /etc/ssl/cert.pem * To allow consistent override of all locations point the symlinks to /usr/local/etc/ssl/cert.pem instead of /usr/local/etc/ssl/cert.pem.sample I'm happy to draft an UPDATING entry and adjust pkg-message accordingly. There are intentional behavioural changes at the benefit of easier user-based handling of /usr/local/etc/ssl/cert.pem modification. For non-modified deployments the resulting behaviour is still the same. Review link: https://reviews.freebsd.org/D47908 Thanks, Franco
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=1abc6bb68665c59c26a5cc65fc5e336d34bb7d88 commit 1abc6bb68665c59c26a5cc65fc5e336d34bb7d88 Author: Franco Fichtner <franco@opnsense.org> AuthorDate: 2025-02-17 11:48:39 +0000 Commit: Dag-Erling Smørgrav <des@FreeBSD.org> CommitDate: 2025-02-17 12:12:15 +0000 security/ca_root_nss: handle bundle links consistently for ETCSYMLINK /usr/local/openssl/cert.pem is the default location for security/openssl so it should be handled just like /etc/ssl/cert.pem base OpenSSL. To avoid having samples and copies with differing contents point both files to the actual /usr/local/etc/ssl/cert.pem created by the sample. If users have set their own content that is likely intended and should be enforced across all three files. MFH: 2025Q1 PR: 283161 Differential Revision: https://reviews.freebsd.org/D47908 security/ca_root_nss/Makefile | 9 +++++---- security/ca_root_nss/pkg-plist | 2 +- 2 files changed, 6 insertions(+), 5 deletions(-)
This is a change in semantics and people will benefit from a head's up. I never cared about (and frankly, explicitly did not want to touch) /etc/ssl/cert.pem, and /usr/local/etc/ssl/cert.pem was installed regardless, so I have had ETCSYMLINK set to OFF on my machines since December 2020. I read "ETCSYMLINK" as "put a symlink in /etc." Now it means "install any and all symlinks." So what happened is that 2 days ago suddenly nothing would start, because of "unable to get local issuer certificate" and I couldn't for the life of me figure out what might have changed. My entire life was basically offline for the last two days until I realized the problem this afternoon. So: this change in semantics will affect some users in a bad way. I'd urge getting the word out. You suggested UPDATING, but that's not my favorite---it's not even present unless one has the ports tree checked out, and users won't see it unless they're intentionally looking for it. The optimal approach here is to set an upgrade message (for < 3.104_1) so that pkg will print it automatically when appropriate. Also I'd adjust pkg-descr so that users are informed about what the flag does (and what happens if they turn it off). And honestly, since the meaning of the flag has just changed (regardless of whether the new behaviour is what was intended from the start), it might be worth changing to a different option, like SYMLINKS or something, so that 'poudriere options' prompts users to examine the new behaviour.
Hi Adam, Thanks for your feedback. Are you using something different than SSL=base? Which application is throwing the error? The point here is to not set up the default bundle for e.g. SSL=openssl and certctl not feeding its default hash dir either (/usr/local/openssl/certs). Besides this implies that base certificates are not even used for SSL=openssl and still rely on the side effect of ca_root_nss being pulled in. Cheers, Franco
Folks, please note https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284749