Re: [gentoo-dev] Re: Last rites: sec-keys/openpgp-keys-jiatan

[Sam James <sam@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2532 bytes --]

Duncan <1i5t5.duncan@cox.net> writes:

> Sam James posted on Wed, 29 May 2024 19:37:47 +0100 as excerpted:
>
>> # Sam James <sam@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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]