From nobody Thu Jan 19 22:48:37 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 4Nyd8T5mH5z2svZP for ; Thu, 19 Jan 2023 22:48:41 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 4Nyd8S49F8z4NF8 for ; Thu, 19 Jan 2023 22:48:40 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp; dmarc=none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 30JMmb35086069 for ; Fri, 20 Jan 2023 07:48:38 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Fri, 20 Jan 2023 07:48:37 +0900 From: Tomoaki AOKI To: ports@freebsd.org Subject: Re: Can security/ca_root_nss be retired? Message-Id: <20230120074837.91ea14559a524f42a3719e3f@dec.sakura.ne.jp> In-Reply-To: <7F3E8043-D985-4BC4-97B9-1FF7BA2E54C1@freebsd.org> References: <20230120070931.4ef522dfa48b35ddac0c50ac@dec.sakura.ne.jp> <7F3E8043-D985-4BC4-97B9-1FF7BA2E54C1@freebsd.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [0.50 / 15.00]; AUTH_NA(1.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-0.95)[-0.951]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_LONG(0.05)[0.045]; MLMMJ_DEST(0.00)[ports@freebsd.org]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; HAS_ORG_HEADER(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[ports@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Queue-Id: 4Nyd8S49F8z4NF8 X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N On Thu, 19 Jan 2023 23:16:46 +0100 Michael Gmelin wrote: > > On 19. Jan 2023, at 23:09, Tomoaki AOKI wrote: > > > > On Thu, 19 Jan 2023 05:58:12 -0800 > > Mel Pilgrim wrote: > > > >>> On 2023-01-19 4:08, Tomoaki AOKI wrote: > >>> On Thu, 19 Jan 2023 03:13:48 -0800 > >>> Mel Pilgrim 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? > > > > Whatever we do, let’s make sure we don’t break existing setups - this needs to be well coordinated. Personally, I don’t want to update (and reboot) the OS in order to get a current list of trusted CAs (at least as long as pkgbase isn’t mainstream this is an issue). > > Michael +1. It's quite an important view point, too. IMHO, certs bundled with base would be better minimalistic, include certs only needed to download pkgs (including pkgbase), https access to FreeBSD project servers (including git repo). Any others would be better maintained as a port/pkg, which is mandated to be installed by bsdinstall. -- Tomoaki AOKI