Re: Can security/ca_root_nss be retired?

On Thu, 19 Jan 2023 05:58:12 -0800
Mel Pilgrim <list_freebsd@bluerosetech.com> wrote:

> On 2023-01-19 4:08, Tomoaki AOKI wrote:
> > On Thu, 19 Jan 2023 03:13:48 -0800
> > Mel Pilgrim <list_freebsd@bluerosetech.com> wrote:
> > 
> >> Given /usr/share/certs exists for all supported releases, is there any
> >> reason to keep the ca_root_nss port?
> > 
> > If everyone in the world uses LATEST main only, yes.
> > But the assumption is clearly nonsense.
> > 
> > Basically, commits to main are settled a while before MFC to stable
> > branches, and MFS to releng branches needs additional settling days.
> > 
> > If any certs happened to be non-reliable, this delay can cause, at
> > worst, catastorphic scenario.
> > 
> > If updates to certs are always promised to be "MFC after: now" and
> > committed to ALL SUPPORTED BRANCHES AT ONCE, I have no objection.
> > 
> > If not, keeping ca_root_nss port and updated ASAP with upstream should
> > be mandatory.
> 
> If ca_root_nss delivered the certs in the same format, sure, but that 
> monolithic file makes installing private CAs a hassle.
> 
> I wonder if the script secteam uses to update the trust store in the src 
> tree could be turned into a periodic script that automatically updates 
> the trust store?  Side-step the release engineering delay entirely by 
> turning trust store updates into a user task.

With the approach, how can we avoid man-in-the-middle attack or
something?

Ports framework has checksum to avoid it, unless local admins
intentionally disable it.

Maybe adding a script to
 *Check if /usr/local/share/certs/ca-root-nss.crt is updated or not.
 *Extract individual certs from ca-root-nss.crt and update trust store.
 *Record current timestamp and hash of ca-root-nss.crt for next run.
into ca-root-nss port, which can be run from cron or by hand, is needed?


-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>