On Thu, Aug 03, 2023 at 02:31:39PM +0000, John Klos wrote: > How it ultimately happens is up to people who understand things better than > I do, but what whould be lovely to see would be: > > 1) a way to install rootcerts in sysinst > > 2) a way to install them post-install, and/or update them > > 3) an easy way for people who have reasons to be deliberate to allow / > block certain certs so that updates don't undo their work
That is exactly what I'd like to see too. I will do (1) immediately once the other two are designed/agreed. I also think that this is NOT a pkgsrc problem, BUT pkgsrc has two very nice property when it comes to (2): the quaterly release cycle, and the independence from the NetBSD release branches. The trust anchors are not really related to any NetBSD branches, so having a global set in -current and always making sure that any changes to it get propagated immediately to all branches is doable but seems a bit like wasted work. And a typical thing that users do is: grab the latest official release (currently that would be the quite ancient 9.3). If the installer offers and on request installs the historic set of trust anchors from that release time, the user might miss quite a few changes. If instead it used something pkgsrc-ish they would get a maximal 3 month outdated version. So using something from pkgsrc, somehow treated specially, and put in a constant place (or: published with a constant URL) in every quaterly release would be nice for installations with network access and for (2) later (automatic) updates. The special handling does not have to happen inside pkgsrc at all - we could have a script that unpacks the amd64 mozilla root certs binary pkg once a new version has been uploaded (or the quaterly symlink switched) and put that data in an arbitrary format (that is understood by sysinst and the [not yet existing] auto-update script) at the fixed URL. In summary I'd be happy to rely on pkgsrc for this, but I don't think we need pkgsrc to make any changes. Martin
