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 6B54D1581F3 for ; Thu, 28 Nov 2024 15:36:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 55C30E08A6; Thu, 28 Nov 2024 15:36:41 +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 457A1E0858 for ; Thu, 28 Nov 2024 15:36:40 +0000 (UTC) Message-ID: <0296ba81-8379-4030-896c-4722cc768d4a@gentoo.org> Date: Thu, 28 Nov 2024 10:36:36 -0500 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 User-Agent: Mozilla Thunderbird Subject: Re: [gentoo-dev] [PATCH v2 1/2] sec-keys.eclass: new eclass To: gentoo-dev@lists.gentoo.org References: <20241127203042.1503004-1-eschwartz@gentoo.org> <20241128043320.1562802-1-eschwartz@gentoo.org> <20241128043320.1562802-2-eschwartz@gentoo.org> Content-Language: en-US From: Eli Schwartz Autocrypt: addr=eschwartz@gentoo.org; keydata= xjMEZmeRNBYJKwYBBAHaRw8BAQdAYNZ7pUDWhx1i2f3p6L2ZLu4FcY18UoeGC04Gq/khqwfN I0VsaSBTY2h3YXJ0eiA8ZXNjaHdhcnR6QGdlbnRvby5vcmc+wpYEExYKAD4WIQTvUdMIsc4j CIi+DYTqQj6ToWND8QUCZoRL+gIbAwUJBKKGAAULCQgHAwUVCgkICwUWAgMBAAIeBQIXgAAK CRDqQj6ToWND8aB5AP9r4kB691nNtNwKkdRiOdl7/k6WYzokvHvDamXxRJ0I+gEAjZqR5V8y mfR3fy2Z+r2Joeqdt3CIv5IwPs64spBvigLOOARmZ5E0EgorBgEEAZdVAQUBAQdATT46Z06b 1X9xjXFCYFxmq/Tj3tSEKZInDWTpoHQp4l8DAQgHwn4EGBYKACYWIQTvUdMIsc4jCIi+DYTq Qj6ToWND8QUCZmeRNAIbDAUJBKKGAAAKCRDqQj6ToWND8a2RAP40KPfbfoiZAJW5boFmFJ3G TUBDJRh9CWHyaPqq2PN+0wD/R07oLzfnJUN209mzi9TuTuHjeZybysyqXSw4MAxkMAY= In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------ZOKxrQsGyYNCDlCbMkW0ojjA" X-Archives-Salt: 48d3ce1b-9a3e-498a-84d1-484a22a06216 X-Archives-Hash: 33a721520b4bbdeffffaec5622eca181 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------ZOKxrQsGyYNCDlCbMkW0ojjA Content-Type: multipart/mixed; boundary="------------0oN1hDSNgCKaHqxfMvR0XsyR"; protected-headers="v1" From: Eli Schwartz To: gentoo-dev@lists.gentoo.org Message-ID: <0296ba81-8379-4030-896c-4722cc768d4a@gentoo.org> Subject: Re: [gentoo-dev] [PATCH v2 1/2] sec-keys.eclass: new eclass References: <20241127203042.1503004-1-eschwartz@gentoo.org> <20241128043320.1562802-1-eschwartz@gentoo.org> <20241128043320.1562802-2-eschwartz@gentoo.org> In-Reply-To: --------------0oN1hDSNgCKaHqxfMvR0XsyR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/28/24 8:10 AM, Micha=C5=82 G=C3=B3rny wrote: > On Wed, 2024-11-27 at 23:32 -0500, Eli Schwartz wrote: >> +# @ECLASS_VARIABLE: SEC_KEYS_VALIDPGPKEYS >> +# @PRE_INHERIT >> +# @DEFAULT_UNSET >> +# @DESCRIPTION: >> +# Mapping of fingerprints, name, and optional location of PGP keys to= include, >=20 > So "location" or "locations", plural? Fixed. >> +# 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.or= g >> +# >> +# - 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. 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. >> + case ${loc} in >> + gentoo) remote=3D"https://keys.gentoo.org/pks/lookup?op=3Dget&se= arch=3D0x${fingerprint}";; >> + github) remote=3D"https://github.com/${name}.gpg";; >> + openpgp) remote=3D"https://keys.openpgp.org/vks/v1/by-fingerprin= t/${fingerprint}";; >> + ubuntu) remote=3D"https://keyserver.ubuntu.com/pks/lookup?op=3Dg= et&search=3D0x${fingerprint}";; >> + # provided via manual SRC_URI >> + none) continue;; >> + *) die "${ECLASS}: unknown PGP key remote: ${loc}";; >> + >=20 > Stray empty line. Fixed. >> +S=3D${WORKDIR} >> + >> +LICENSE=3D"public-domain" >> +SLOT=3D"0" >=20 > Please keep ebuildy variables in the standard/skel order, or at least > as close to it as you can get. Fixed. >> +# @FUNCTION: sec-keys_src_compile >> +# @DESCRIPTION: >> +# Default src_compile override that imports all public keys into a ke= yring, >> +# and validates that they are listed in SEC_KEYS_VALIDPGPKEYS. >> +sec-keys_src_compile() { >> + local -x GNUPGHOME=3D${WORKDIR}/gnupg >> + mkdir -m700 -p "${GNUPGHOME}" || die >> + >> + pushd "${DISTDIR}" >/dev/null || die >> + gpg --import ${A} || die >> + popd >/dev/null || die >> + >> + local line imported_keys=3D() found=3D0 >> + while IFS=3D: read -r -a line; do >> + if [[ ${line[0]} =3D pub ]]; then >=20 > Please use '=3D=3D' in ebuilds and eclasses. =2E.. >> + # 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-colons= || die) >=20 > Why do you need --keyid-format? You're using fingerprints only, aren't= > you? I'm used to it mattering in various contexts and added it instinctively. You're right, it doesn't do anything here. >> + >> + printf '%s\n' "${imported_keys[@]}" | sort > imported_keys.list || d= ie >> + printf '%s\n' "${SEC_KEYS_VALIDPGPKEYS[@]%%:*}" | sort > allowed_key= s.list || die >> + >> + local extra_keys=3D($(comm -23 imported_keys.list allowed_keys.list = || die)) >> + local missing_keys=3D($(comm -13 imported_keys.list allowed_keys.lis= t || die)) >> + >> + if [[ ${#extra_keys[@]} !=3D 0 ]]; then >> + die "too many keys found. Suspicious keys: ${extra_keys[@]}" >=20 > The first sentence is not capitalized. Fixed. >> + 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 > "${finger= print}.pgpdump" || die >> + done >> + >> + # Best-effort attempt to check for updates. keyservers can and usual= ly do >> + # fail for weird reasons, (such as being unable to import a key with= out 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. This doesn't test a useful property. 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. Removing a key for whatever reason, doesn't tell you why it was removed, or even who removed it. It is also not how the PGP standard says you are supposed to handle a *compromised* key. It's not like GnuPG will delete keys from your keyring if the server doesn't possess it anymore... there is actually no such thing as a user of PGP that would be correctly served by someone removing a compromised key in the hopes that those users would interpret it as an indicator of compromise. In exchange for no assurances whatsoever, the code would become a lot more complicated. As I already said, gpg exiting with something other than 0 for success can mean many things and there's no good way to figure out what it did in fact mean. I'm going to need a better argument if you want me to change this. >> +sec-keys_src_install() { >> + local -x GNUPGHOME=3D${WORKDIR}/gnupg >> + local fingerprint >> + local gpg_command=3D(gpg --no-permission-warning --export-options ex= port-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 --armo= r "${fingerprint}" >> ${PN#openpgp-keys-}.asc >> + done >=20 > That looks like something you could do in src_compile() already. 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. I guess I am not too attached to either approach. > 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? Because this is doing additional steps that aren't just exporting the whole thing? --=20 Eli Schwartz --------------0oN1hDSNgCKaHqxfMvR0XsyR-- --------------ZOKxrQsGyYNCDlCbMkW0ojjA Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCZ0iOBAUDAAAAAAAKCRCEp9ErcA0vV978 APoCD/YpE7pL9nVYQkpeNAFyjQ0lQjsm0Hj1eNj6XldbCgD/R0FPzql12zKpK5wQaIjaHPD815q1 U7GTVFVevWraIAk= =gcb2 -----END PGP SIGNATURE----- --------------ZOKxrQsGyYNCDlCbMkW0ojjA--