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 5FB3F1581F3 for ; Wed, 27 Nov 2024 21:12:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7198FE08A6; Wed, 27 Nov 2024 21:12:53 +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)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 97CEAE07F1 for ; Wed, 27 Nov 2024 21:12:52 +0000 (UTC) Message-ID: <796bd145558001d054ee56ec23eed31385ae453a.camel@gentoo.org> Subject: Re: [gentoo-dev] [PATCH 1/2] sec-keys.eclass: new eclass From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Wed, 27 Nov 2024 22:12:47 +0100 In-Reply-To: <20241127203042.1503004-1-eschwartz@gentoo.org> References: <20241127203042.1503004-1-eschwartz@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-+YSe+IxfNRIJdfy0ISzM" User-Agent: Evolution 3.52.4 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 X-Archives-Salt: 7d311d26-0f54-4c03-bfe9-81fdf9beafd1 X-Archives-Hash: ed173e81ce735465a01dbd971b1fe4c3 --=-+YSe+IxfNRIJdfy0ISzM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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? --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-+YSe+IxfNRIJdfy0ISzM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQFGBAABCgAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmdHi08SHG1nb3JueUBn ZW50b28ub3JnAAoJEGOa2uIyniQOxEMH/jxzRwUcVWVUGa61wIdSgb+sZRzEVnHv kUknR+yl0RfjnZ331U4gfRJPdEcrvWeviNel66Edh1R99637R0R07S4xqZNV+RUd Yjoj8opwMO0cVAKtHUkjcKF8TMsSy3nR40mmkuGSaUqQK1/fCFT5wsfkp6DfAECt PvoB9QcU+NDkVcWm+iPOS5MX4Xvx4oQ6yMMUJDHk455RtXSvR98yWN0iOwQjkA1R y7cCe8ZCAYijCg0pG3m6socerrc94Iq3G8YpQvbsdv+q6kUL/WnV5V0GTj8XNM66 qwY47M3Nclr1ml94PhvKed37p+nFuH9VCSR4YcPNinblaCSo6stK+Zo= =3IYH -----END PGP SIGNATURE----- --=-+YSe+IxfNRIJdfy0ISzM--