From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 3CD3F1581F3 for ; Wed, 27 Nov 2024 21:52:23 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 90635E08BB; Wed, 27 Nov 2024 21:52:18 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (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) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B1318E08A6 for ; Wed, 27 Nov 2024 21:52:17 +0000 (UTC) From: Sam James To: =?utf-8?B?TWljaGHFgiBHw7Nybnk=?= Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PATCH 1/2] sec-keys.eclass: new eclass In-Reply-To: <796bd145558001d054ee56ec23eed31385ae453a.camel@gentoo.org> (=?utf-8?Q?=22Micha=C5=82_G=C3=B3rny=22's?= message of "Wed, 27 Nov 2024 22:12:47 +0100") Organization: Gentoo References: <20241127203042.1503004-1-eschwartz@gentoo.org> <796bd145558001d054ee56ec23eed31385ae453a.camel@gentoo.org> User-Agent: mu4e 1.12.7; emacs 31.0.50 Date: Wed, 27 Nov 2024 21:52:13 +0000 Message-ID: <871pywuyya.fsf@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 1d71a78e-acda-4a72-8ba8-e9f4e7476523 X-Archives-Hash: 94744e69da44d3fadc116375a6779894 Micha=C5=82 G=C3=B3rny writes: > On Wed, 2024-11-27 at 15:30 -0500, Eli Schwartz wrote: >> The current state of verify-sig support is a bit awkward. We rely on >> validating distfiles against a known trusted keyring, but creating the >> known trusted keyring is basically all manual verification. We somehow >> decide an ascii armored key is good enough without any portage >> assistance, then arrange to download it and trust it by Manifest hash. >> How do we know when updating a key is actually safe? >>=20 >> This eclass handles the problem in a manner inspired in part by pacman. >> We require an eclass variable that lists all permitted PGP fingerprints, >> and the eclass is responsible checking that list against the keys we >> will install. It comes with a mechanism for computing SRC_URI for a >> couple of well known locations, or you can append your own in the >> ebuild. > > How about adding a src_test() that would check if the key needs bumping, > i.e. if an online update triggers any meaningful changes? Ooh, I like this idea. We could print a pgpdump diff.