Re: pkg update broke

> On Jul 6, 2026, at 11:28=E2=80=AFAM, Marco Moock <[email protected]> =
wrote:
>=20
> Am 06.07.26 um 16:04 schrieb William F. Dudley Jr.:
>> relax, it's just a debugging step.  I don't plan to do that forever.
>=20
> Although it is enough to compromise a system, even if the probability =
is low.

Waitaminute,

How (better question: WHY) does ca_root_nss figure in to pkg?

The system has its own trust store, shipped as part of base and =
maintained with freebsd-update, rehashed on any update.  =
Pkg/fetch/freebsd-update/etc uses it.  The need for ca_root_nss is =
slowly diminishing, and most of my systems don't have it as an =
auto-dependency at all (I don't know which ports still haven't been =
massaged to just use the system store by default).  I do wonder how many =
users who have it as a result of some long-ago dependency could just =
autoremove it and be fine.

Evidence: You can run pkg or freebsd-update or fetch https://google.com =
on a system with no installed packages.  Pkg itself is an installed pkg =
(not in base) but...it also doesn't install ca_root_nss as a dependency.

The bug here is pkg also looks for a monolithic CAFile (which was =
installed by ca_root_nss, and was damaged in OP's case), and if reading =
your CAFile breaks (fails to load) for some reason, the invocation as =
called by libfetch doesn't properly fall back to trying the CAPath.

This seems counterintuitive in the use-case of pkg, where a damaged port =
can break a core util.  I'd argue that pkg should have used only use the =
system stores.  If a user needs to somehow trust a private CA/cert for a =
pkg repo, they can do it via the usual /usr/local/share/certs & certctl =
mechanisms.

Also, thanks to [an hour I won't get back of...] looking into openssl =
invocations, the openssl s_client command line worked but pkg failed =
because openssl s_client is more forgiving and didn't bail out of =
loading the CA paths when the CAFile load failed, when called with no =
-CAFile/-CAPath args.  If I had told OP to specify those, we probably =
would have seen the failure, but there's likely no way to tell now that =
user's back up and running.

-Dan=