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 817A71581F3 for ; Thu, 28 Nov 2024 16:42:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 73D48E081E; Thu, 28 Nov 2024 16:42:36 +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 9F565E07F1 for ; Thu, 28 Nov 2024 16:42:35 +0000 (UTC) Message-ID: <3a2185ab4add82e047d3e47912429323df5bf5a5.camel@gentoo.org> Subject: Re: [gentoo-dev] [PATCH v2 1/2] sec-keys.eclass: new eclass From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Thu, 28 Nov 2024 17:42:29 +0100 In-Reply-To: <0296ba81-8379-4030-896c-4722cc768d4a@gentoo.org> References: <20241127203042.1503004-1-eschwartz@gentoo.org> <20241128043320.1562802-1-eschwartz@gentoo.org> <20241128043320.1562802-2-eschwartz@gentoo.org> <0296ba81-8379-4030-896c-4722cc768d4a@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-zIQjqTj5zLNAICGeXp7R" 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: 1996828c-7808-4de0-9f0b-c11dd1458a1f X-Archives-Hash: 06e45e57d88e24412515daa448e5f258 --=-zIQjqTj5zLNAICGeXp7R Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2024-11-28 at 10:36 -0500, Eli Schwartz wrote: > On 11/28/24 8:10 AM, Micha=C5=82 G=C3=B3rny wrote: >=20 > > > +# separated by colons. The allowed values for a location are: > > > +# > > > +# - gentoo -- fetch key by fingerprint from https://keys.gentoo.org > > > +# > > > +# - github -- fetch key from github.com/${name}.pgp > > > +# > > > +# - openpgp -- fetch key by fingerprint from https://keys.openpgp.o= rg > > > +# > > > +# - ubuntu -- fetch key by fingerprint from http://keyserver.ubuntu= .com (the default) > >=20 > > I'd go without a default. Typing 6 more letters doesn't cost anything, > > and makes the contents more consistent. Also saves us from regretting > > having chosen a bad default in the future. > >=20 > > > +# > > > +# - none -- do not add to SRC_URI, the ebuild will provide a custom= download location > >=20 > > Perhaps "manual"? "None" sounds like there would be no key at all. >=20 >=20 > Maybe I could just document as a recommendation to use ubuntu. Other > sources are likely to be extremely unreliable, unfortunately. > openpgp.org only works if the key owner manually verifies their email, > for example. Yeah. I don't see why anyone would specify a non-working location (such as openpgp.org). > > > + # new key > > > + found=3D0 > > > + elif [[ ${found} =3D 0 && ${line[0]} =3D fpr ]]; then > > > + # primary fingerprint > > > + imported_keys+=3D("${line[9]}") > > > + found=3D1 > > > + fi > > > + done < <(gpg --batch --list-keys --keyid-format=3Dlong --with-colon= s || die) > >=20 > > Why do you need --keyid-format? You're using fingerprints only, aren't > > you? >=20 >=20 > I'm used to it mattering in various contexts and added it instinctively. > You're right, it doesn't do anything here. Yeah. And for a minute, it made me worry that you're using long ids instead of fingerprints. > > > + fi > > > + if [[ ${#missing_keys[@]} !=3D 0 ]]; then > > > + die "too few keys found. Unavailable keys: ${missing_keys[@]}" > > > + fi > > > +} > > > + > > > + > > > +sec-keys_src_test() { > > > + local -x GNUPGHOME=3D${WORKDIR}/gnupg > > > + local key fingerprint name server > > > + local gpg_command=3D(gpg --export-options export-minimal) > > > + > > > + for fingerprint in "${SEC_KEYS_VALIDPGPKEYS[@]%%:*}"; do > > > + "${gpg_command[@]}" --export "${fingerprint}" | pgpdump > "${finge= rprint}.pgpdump" || die > > > + done > > > + > > > + # Best-effort attempt to check for updates. keyservers can and usua= lly do > > > + # fail for weird reasons, (such as being unable to import a key wit= hout a > > > + # uid) as well as normal reasons, like the key being exclusive to a > > > + # different keyserver. this isn't a reason to fail src_test. > >=20 > > Well, I dare say that if refreshing against the server specified > > as the reference source fails, that would count as a reason to fail.= =20 > > Consider the case of someone removing a compromised key instead > > of revoking it. >=20 >=20 > This doesn't test a useful property. >=20 > People cannot "remove" compromised keys from a keyserver to begin with. > If they did, then checking to build the package with GENTOO_MIRRORS=3D > DISTDIR=3D$(mktemp -d) is a significantly more useful test. In fact, this is the kind of test I was originally thinking of -- i.e. literally refetching the file manually and seeing if the minimal export differs... > > > +sec-keys_src_install() { > > > + local -x GNUPGHOME=3D${WORKDIR}/gnupg > > > + local fingerprint > > > + local gpg_command=3D(gpg --no-permission-warning --export-options e= xport-minimal) > > > + > > > + for fingerprint in "${SEC_KEYS_VALIDPGPKEYS[@]%%:*}"; do > > > + local uids=3D() > > > + mapfile -t uids < <("${gpg_command[@]}" --list-key --with-colons $= {fingerprint} | awk -F: '/^uid/{print $10}' || die) > > > + edo "${gpg_command[@]}" "${uids[@]/#/--comment=3D}" --export --arm= or "${fingerprint}" >> ${PN#openpgp-keys-}.asc > > > + done > >=20 > > That looks like something you could do in src_compile() already. >=20 >=20 > Perhaps. But it felt like exporting keys is work that is conceptually > part of installing, in much the way that running a meson project's > `meson install` step does more than just copy files into ${D} -- it also > processes those files in order to do things like patch the rpath. >=20 > I guess I am not too attached to either approach. >=20 >=20 > > Also, I'm confused by the purpose of this whole logic. After all, you > > have already verified that there are no stray keys in the keyring, > > right? So why not just export the whole thing? >=20 >=20 > Because this is doing additional steps that aren't just exporting the > whole thing? >=20 Then perhaps you should add an explanatory comment instead of expecting people to catch that from a command so long it doesn't fit on people's screens. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-zIQjqTj5zLNAICGeXp7R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQFGBAABCgAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmdInXUSHG1nb3JueUBn ZW50b28ub3JnAAoJEGOa2uIyniQO1kEH/jJw9pvr8kCOqwLwTRpuMvgqQQlsUv+R KxqI5IU8kwU86TaDMvMyx4Apld+qvr8YTPhInfCcDZlcGEs75yxtlD0Z0KkoY81V Ye/BBIWftspaMWTBVHYS2PAqXVDWH6AAk61/uq+8vKojehB3kLmq3rZJjTE2a0gO 0BuwNq6vGCSKCYP9ZXFvtOH/B5yF6nd0diTNlgUmKbWUQ0IBSv4qEsJ/LJhRxd/o Y8CJHWA47o46EVq8XTsX5QvobDFaO7yrjT+X5eDE7UzF0Sb9TjLs4Dr1j3nAFIOV rpwOYRoK+FO7p00W9O4lltxyAkcl6pLmkWZ74OUyjF4TO0S/sxVb90s= =R9HB -----END PGP SIGNATURE----- --=-zIQjqTj5zLNAICGeXp7R--