1. Forum
  2. Usenet
  3. LINUX.GENTOO.DEV

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

    From Sam James@21:1/5 to All on Wed May 29 20:40:01 2024
    # Sam James <[email protected]> (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)
  • From Duncan@21:1/5 to All on Thu May 30 08:50:01 2024
    Sam James posted on Wed, 29 May 2024 19:37:47 +0100 as excerpted:

    # Sam James <[email protected]> (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)
  • From Ulrich Mueller@21:1/5 to All on Thu May 30 09:50:02 2024
    On Wed, 29 May 2024, Sam James wrote:

    # Sam James <[email protected]> (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)
  • From Sam James@21:1/5 to Ulrich Mueller on Thu May 30 16:00:01 2024
    Ulrich Mueller <[email protected]> writes:

    On Wed, 29 May 2024, Sam James wrote:

    # Sam James <[email protected]> (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)
  • From Sam James@21:1/5 to Duncan on Thu May 30 16:00:01 2024
    Duncan <[email protected]> writes:

    Sam James posted on Wed, 29 May 2024 19:37:47 +0100 as excerpted:

    # Sam James <[email protected]> (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)