From nobody Fri Jan 20 02:36:25 2023 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NykCM2YtYz2v6nj for ; Fri, 20 Jan 2023 02:36:31 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from echo.brtsvcs.net (echo.brtsvcs.net [IPv6:2607:f740:c::4ae]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NykCM07g6z3jZg for ; Fri, 20 Jan 2023 02:36:30 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Authentication-Results: mx1.freebsd.org; none Received: from chombo.houseloki.net (65-100-43-2.dia.static.qwest.net [65.100.43.2]) by echo.brtsvcs.net (Postfix) with ESMTPS id 61F2738D0D; Fri, 20 Jan 2023 02:36:26 +0000 (UTC) Received: from [10.26.25.100] (ivy.pas.ds.pilgrimaccounting.com [10.26.25.100]) by chombo.houseloki.net (Postfix) with ESMTPSA id 0BE8524DBE; Thu, 19 Jan 2023 18:36:26 -0800 (PST) Subject: Re: Can security/ca_root_nss be retired? To: Tomoaki AOKI , ports@freebsd.org References: <551458a3-665f-9f55-8ef9-1dd23e1e3aee@bluerosetech.com> <20230119210801.97b4eef4e21b96d40721b31a@dec.sakura.ne.jp> <20230120070931.4ef522dfa48b35ddac0c50ac@dec.sakura.ne.jp> From: Mel Pilgrim Message-ID: <7874b086-eb2f-ef79-f013-c840d4908018@bluerosetech.com> Date: Thu, 19 Jan 2023 18:36:25 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 In-Reply-To: <20230120070931.4ef522dfa48b35ddac0c50ac@dec.sakura.ne.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4NykCM07g6z3jZg X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36236, ipnet:2607:f740:c::/48, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 2023-01-19 14:09, Tomoaki AOKI wrote: > On Thu, 19 Jan 2023 05:58:12 -0800 > Mel Pilgrim 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?