While LetsEncrypt has had recent changes, I've noticed the following: Pidgin exclusively uses net-im/libpurple's bundled TLS certs, and doesn't use FreeBSD's own store of TLS certs. This means even if FreeBSD utilities can connect to services using recent LetsEncrypt certificates, Pidgin refuses to connect. (for example, the jabber.at XMPP server) I feel it would be nice if libpurple or Pidgin could be configured to use the OS's TLS certificates. I think this is probably a ports/package issue, but if I should report this upstream instead, let me know. package versions: libpurple-2.14.4 pidgin-2.14.4 $ uname -a FreeBSD nyann.tanasinn.mochi 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #0: Tue Aug 24 07:33:27 UTC 2021 root@amd64-builder.daemonology.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 $ freebsd-version -kru 13.0-RELEASE-p4 13.0-RELEASE-p4 13.0-RELEASE-p5
I'll note that libpurple's bundled certificates are up to date in the latest version (though that package isn't available on quarterly yet) Even so, it might be preferable to have the packages using FreeBSD's certs. How do other ports handle this?
Ping. I found this bug ca be solved by the following: mv /usr/local/share/purple/ca-certs /somewhere/else I think the correct solution would be to not bundle libpurple's certs.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=c80dda3bf578ae5c0e9e02beec4a1be2609f0d44 commit c80dda3bf578ae5c0e9e02beec4a1be2609f0d44 Author: Joe Marcus Clarke <marcus@FreeBSD.org> AuthorDate: 2021-12-26 16:04:38 +0000 Commit: Joe Marcus Clarke <marcus@FreeBSD.org> CommitDate: 2021-12-26 16:04:38 +0000 net-im/libpurple: Point to the system TLS certs. PR: 259954 net-im/libpurple/Makefile | 4 +++- net-im/libpurple/pkg-plist | 3 --- 2 files changed, 3 insertions(+), 4 deletions(-)
Fixed in 2.14.8_1. It should now point to the system TLS certs.
This is foxed now.