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 E6A271581F3 for ; Thu, 28 Nov 2024 04:17:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 49887E07C9; Thu, 28 Nov 2024 04:17:38 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 EBD83E077A for ; Thu, 28 Nov 2024 04:17:36 +0000 (UTC) Message-ID: Date: Wed, 27 Nov 2024 23:17:32 -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 From: Eli Schwartz Subject: Re: [gentoo-dev] [PATCH 1/2] sec-keys.eclass: new eclass To: Sam James Cc: gentoo-dev@lists.gentoo.org References: <20241127203042.1503004-1-eschwartz@gentoo.org> <87plmgtk4a.fsf@gentoo.org> Content-Language: en-US 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: <87plmgtk4a.fsf@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------z0WB4GMCwoJrjHN7F4T3zNtn" X-Archives-Salt: 88d722ae-2efa-4ac9-80eb-01525b6b2010 X-Archives-Hash: 5ca1947ae2ca4c5521dcde9bdca06320 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------z0WB4GMCwoJrjHN7F4T3zNtn Content-Type: multipart/mixed; boundary="------------LLYwgcOUprV5g0x91Fk8Spa0"; protected-headers="v1" From: Eli Schwartz To: Sam James Cc: gentoo-dev@lists.gentoo.org Message-ID: Subject: Re: [gentoo-dev] [PATCH 1/2] sec-keys.eclass: new eclass References: <20241127203042.1503004-1-eschwartz@gentoo.org> <87plmgtk4a.fsf@gentoo.org> In-Reply-To: <87plmgtk4a.fsf@gentoo.org> --------------LLYwgcOUprV5g0x91Fk8Spa0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/27/24 4:57 PM, Sam James wrote: > Eli Schwartz writes: >> +# @EXAMPLE: >> +# Example use: >> +# >> +# @CODE >> +# SEC_KEYS_VALIDPGPKEYS=3D( >> +# '4EC8A4DB7D2E01C00AF36C49E5C587B5E286C65A:jsmith:github' >> +# ) >=20 > Can you expand the example(s) here maybe with some comments in the arra= y > to help people see when it might be suitable to use e.g. none with a mi= x > of github? Sure, good idea. >> +# @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 >=20 > Is there any value in using gemato's gpg-wrap for this function? I don't think so. The main use case for gemato that I see is it automatically entering a tempdir context based on a keyfile. We need to support multiple keyfiles, including ebuild-specified SRC_URI that may not be ascii-armored and cannot be concatenated together, which means in order to get to a point where gpg-wrap can be used to run one-off commands using a keyfile in which gemato wraps the creation of a keyring... we've basically done all the work we actually wanted to do. >> + 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)) >=20 > Any reason to not readarray this instead? The files each contain a list of words (PGP fingerprint, consisting of characters matching [0-9A-F] and nothing else), with the only whitspace in the file being newline characters. Both readarray and command substitution tokenize this the same. I'm not sure it particularly matters which one to use, but command substitution can be done on one line (local variable=3D($(command || die)) ) whereas readarray requires two lines (local -a variable; readarray -t varlist < <(command || die) ) and you have to remember to use -t and -a. I don't think readarray provides any functionality we need here. >> + 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 || die >=20 > No need for the die here. Right, I probably forgot to remove this when I switched to edo. --=20 Eli Schwartz --------------LLYwgcOUprV5g0x91Fk8Spa0-- --------------z0WB4GMCwoJrjHN7F4T3zNtn Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCZ0fu3AUDAAAAAAAKCRCEp9ErcA0vV2Zs AP9MTo2j8q9MwUcC5vOeDZVjXzw10mHNApcnQZfRWnPPgQD/QNImdJC4ID06oTSmSeDFn62Y2/I9 YJ9AiKOTqHiBtwY= =J42X -----END PGP SIGNATURE----- --------------z0WB4GMCwoJrjHN7F4T3zNtn--