Re: Can security/ca_root_nss be retired?
- In reply to: Tomoaki AOKI : "Re: Can security/ca_root_nss be retired?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 20 Jan 2023 02:36:25 UTC
On 2023-01-19 14:09, Tomoaki AOKI wrote: > On Thu, 19 Jan 2023 05:58:12 -0800 > Mel Pilgrim <list_freebsd@bluerosetech.com> wrote: >> 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? By using the root trust store already on the system. > Ports framework has checksum to avoid it, unless local admins > intentionally disable it. The distinfo check only asserts that what the user downloaded is very likely the same as what the maintainer downloaded. The makesum target enables SSL peer verification during the fetch phase, so ultimately the MitM-mitigation in the Ports System is just the root trust store. > 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? Since that would only need to be run after the port gets updated, it makes sense to me that it should be part of the port's install process. Is there a technical reason why the port can't, during the post-install target, create in /usr/local/share/certs/trusted and /usr/local/etc/ssl/certs the same structure as the in-base trust store?