Duncan <1i5t5.dun...@cox.net> writes: > Sam James posted on Wed, 29 May 2024 19:37:47 +0100 as excerpted: > >> # Sam James <s...@gentoo.org> (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 commit > tags so people unfamiliar with the story coming across this in the git > history say five years from now can easily see that Gentoo took the proper > 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 > 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 > the bad packages/package-versions? I've no explanation how it could > happen without a (n entirely theoretical, AFAIK) gentoo-level accomplice > outing themselves, but it would sure look bad if some how, some way, > something (even in an overlay) inexplicably started using such a key again > while it was still in-tree. Maybe even provide an expedited security > 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.
signature.asc
Description: PGP signature
