From nobody Thu Jan 19 22:16:46 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 4NycRk42M6z2sqc7 for ; Thu, 19 Jan 2023 22:16:50 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NycRj5XYLz4L2Y for ; Thu, 19 Jan 2023 22:16:49 +0000 (UTC) (envelope-from grembo@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 4205919f; Thu, 19 Jan 2023 22:16:47 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 17955d04 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Thu, 19 Jan 2023 22:16:47 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (1.0) Subject: Re: Can security/ca_root_nss be retired? From: Michael Gmelin In-Reply-To: <20230120070931.4ef522dfa48b35ddac0c50ac@dec.sakura.ne.jp> Date: Thu, 19 Jan 2023 23:16:46 +0100 Cc: ports@freebsd.org Message-Id: <7F3E8043-D985-4BC4-97B9-1FF7BA2E54C1@freebsd.org> References: <20230120070931.4ef522dfa48b35ddac0c50ac@dec.sakura.ne.jp> To: Tomoaki AOKI X-Mailer: iPhone Mail (20B110) X-Rspamd-Queue-Id: 4NycRj5XYLz4L2Y X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > On 19. Jan 2023, at 23:09, Tomoaki AOKI wrote:= >=20 > =EF=BB=BFOn Thu, 19 Jan 2023 05:58:12 -0800 > Mel Pilgrim wrote: >=20 >>> On 2023-01-19 4:08, Tomoaki AOKI wrote: >>> On Thu, 19 Jan 2023 03:13:48 -0800 >>> Mel Pilgrim wrote: >>>=20 >>>> Given /usr/share/certs exists for all supported releases, is there any >>>> reason to keep the ca_root_nss port? >>>=20 >>> If everyone in the world uses LATEST main only, yes. >>> But the assumption is clearly nonsense. >>>=20 >>> Basically, commits to main are settled a while before MFC to stable >>> branches, and MFS to releng branches needs additional settling days. >>>=20 >>> If any certs happened to be non-reliable, this delay can cause, at >>> worst, catastorphic scenario. >>>=20 >>> If updates to certs are always promised to be "MFC after: now" and >>> committed to ALL SUPPORTED BRANCHES AT ONCE, I have no objection. >>>=20 >>> If not, keeping ca_root_nss port and updated ASAP with upstream should >>> be mandatory. >>=20 >> If ca_root_nss delivered the certs in the same format, sure, but that=20 >> monolithic file makes installing private CAs a hassle. >>=20 >> I wonder if the script secteam uses to update the trust store in the src=20= >> tree could be turned into a periodic script that automatically updates=20= >> the trust store? Side-step the release engineering delay entirely by=20 >> turning trust store updates into a user task. >=20 > With the approach, how can we avoid man-in-the-middle attack or > something? >=20 > Ports framework has checksum to avoid it, unless local admins > intentionally disable it. >=20 > 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? >=20 Whatever we do, let=E2=80=99s make sure we don=E2=80=99t break existing setu= ps - this needs to be well coordinated. Personally, I don=E2=80=99t want to u= pdate (and reboot) the OS in order to get a current list of trusted CAs (at l= east as long as pkgbase isn=E2=80=99t mainstream this is an issue). Michael