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 (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 83E5E1581D3 for ; Thu, 30 May 2024 13:50:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7BE12E2A42; Thu, 30 May 2024 13:50:52 +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 2D71FE2A38 for ; Thu, 30 May 2024 13:50:52 +0000 (UTC) From: Sam James To: Duncan <1i5t5.duncan@cox.net> Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Last rites: sec-keys/openpgp-keys-jiatan In-Reply-To: (Duncan's message of "Thu, 30 May 2024 06:49:32 -0000 (UTC)") Organization: Gentoo References: <875xuwfoqs.fsf@gentoo.org> Date: Thu, 30 May 2024 14:50:46 +0100 Message-ID: <87wmnbe7d5.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: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Archives-Salt: d9a94a5d-9520-400c-ab8f-7382ee5fcd1c X-Archives-Hash: 5630fa9b075ad0bcc38ff285a00deb81 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Duncan <1i5t5.duncan@cox.net> writes: > Sam James posted on Wed, 29 May 2024 19:37:47 +0100 as excerpted: > >> # Sam James (2024-05-29) >> # OpenPGP key of malicious xz co-maintainer. This key is no longer used >> # by any ebuilds in tree. Removal on 2024-06-29. >> # Bug #928134. >> sec-keys/openpgp-keys-jiatan > > I'd suggest adding the xzutils GLSA and/or version mask and removal commi= t=20 > tags so people unfamiliar with the story coming across this in the git=20 > history say five years from now can easily see that Gentoo took the prope= r=20 > actions with appropriate timing. > I can mention the GLSA explicitly, I suppose, but people can read the bug anyway. I did try to be verbose in the various commits for this (which you can see on the bug) already. > Also, might not hurt to make that "malicious xz upstream former co- > maintainer" or some such, making even clearer that it wasn't gentoo-level= =20 > package-maintainer, and that they *ARE* former. But yes, a fair point on mentioning it was an upstream co-maintainer instead. I'll change that later. > > Finally, could we update security practices (maybe it's already in- > process?) to ensure the bad key is masked and removed earlier, along with= =20 > the bad packages/package-versions? I've no explanation how it could=20 > happen without a (n entirely theoretical, AFAIK) gentoo-level accomplice= =20 > outing themselves, but it would sure look bad if some how, some way,=20 > something (even in an overlay) inexplicably started using such a key agai= n=20 > while it was still in-tree. Maybe even provide an expedited security=20 > exception of some sort from normal tree-cleaning procedures for the sec- > keys category? As I explained in the commit message(s), I deliberately didn't remove 5.4.6 prematurely - although it was masked the whole time, and remains so - because I didn't want to contribute to confusion about what is, and isn't, known to be bad. I also explained this in the bug as we went. I don't really think anything using the key would be meaningful at all, given how verify-sig works. It's primarily a tool for ebuild maintainers to ease verification of signatures. It doesn't lend something extra legitimacy. Also, the keyring package has been masked the whole time -- now I'm just *last-riting* it. So, sure, I guess I could have, but then I would've been removing verify-sig from 5.4.6 for theatre and it didn't feel like a great use of time when there was real work to be doing. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZliEN18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZCKugEAn6THkYXNm1vEeF4j3dX9EPw5VqXB5X8chcWF lpeFT3AA/RX2SNmg9mLN1ccVjNdrC9jEbT/EYDd3uFNlnIHLfMcN =hi7c -----END PGP SIGNATURE----- --=-=-=--