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

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

[Sam James]

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

# 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

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

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

[Duncan]

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.

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.

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?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[Ulrich Mueller]

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

>>>>> On Wed, 29 May 2024, Sam James wrote:

> # 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

Just out of interest, by what chain of trust was this key added, in the
first place?

Ulrich

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

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

[Sam James]

[-- 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 --]

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

[Sam James]

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

Ulrich Mueller <ulm@gentoo.org> writes:

>>>>>> On Wed, 29 May 2024, Sam James wrote:
>
>> # 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
>
> Just out of interest, by what chain of trust was this key added, in the
> first place?

I have been a member of the xz community for several years and was
around before Jia came into the picture, and was around as he became a
contributor, developer, and eventually co-maintainer. Him being a
release manager was not a surprise and it was done with Lasse's consent
(although, as we now know, he felt pressured into it).

That is, there's no chain of trust verification which would've helped here. That
said, his key was signed by Lasse's anyway.

But in general for verify-sig stuff, we tend to rely on TOFU for new
packages, some sort of statement where possible / signing for changing
in keys from the same person or a new release manager, but it's not
always
possible.

>
> Ulrich

thanks,
sam

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