# 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

-----BEGIN PGP SIGNATURE-----

iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZld1/F8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZAriAD/aMRcQv5kUXFSCkeuR5FqVGAPIwfC9n0Ot1pV ny8xDScBAP74cXy12tkj5ntyQZ5LEabhmzPQp6yKYKgkGD56XHsO
=OMoR
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmZYLgMPHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4u75IH/jN6ZfXCeYNJHCsh5KK+2RvwGRXKO2dMQM0t WGxgomL5N64TTYPCxFumXG+ntqLKiQS7BBdQ6Fs43KYg995DkkmFIEJER4P6nq/y thq/k5sMEdyU1uDw+nS0UUquU+/fWsHxxOiQuxsOhwBqpfoyM7CuJ+liY7Yl8xK5 BoP8hsjpKXvfZiUyr2jDDpLJe6/1mqrIJisq5qdP+ZpWmpBAn6eZgjGNqEzVfXSv AdvqNXJEyODAAMJbkFQoposPZ/FdU6IQxFHO9sMZQtXSEFp3PR5OyLiSezmaslnj Hn+Otl3WRACn9yy4W7rQ2LOgNKAgKwM3StRMGREm3SjJ5oj2bsw=
=GUgl
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZliEzF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZChjQEA0eRxfH+qPBnVAG4k3veq2yjHq2J87WMctRBV 2I8rTQMA/RjJeQbfXP5lw1X/BXPnMp3enK/hpJxOAPcexX5/NvUJ
=XFuY
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZliEN18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZCKugEAn6THkYXNm1vEeF4j3dX9EPw5VqXB5X8chcWF lpeFT3AA/RX2SNmg9mLN1ccVjNdrC9jEbT/EYDd3uFNlnIHLfMcN
=hi7c
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)