Notices by see shy jo (joeyh@hachyderm.io), page 3

@cesarb hmm, good point git am en masse followed by a rebase. If you also did a git am of your own patches in addition to the other persons's

anyone know of a common #git workflow that would result in 4 commits with 2 separate authors all having one timestamp as a common commit timestamp and a second timestamp as a common author timestamp?

a rebase would explain the common commit timestamps, but it preserves author timestamp

this seems a little suspicious, but maybe there is some other workflow that explains it

Checked all xz commit timestamps for similar patterns. first is a series of commits by Jia Tan on Jan 19, then another Jan 22, then Lasse has a series on Feb 9, then a long series that includes the commits mentioned above, then 3 more series by Lasse on Feb 17 and Feb 29. This certainly seems unusual.

but, I do find similar things in git.git history, Junio has a workflow that results in that legitinately

This suggests to me that xz's git workflow changed in January.

@demize thanks, I really know nothing about RE. Sounds like a real game of core wars

how common is it for malware to have anti-breakpoint checking in it?

curious because the #xz backdoor does: https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504#software-breakpoint-check-method-1

I rag on github a whole lot, but this is one feature it has that I really like.

Since JiaT75 backdoored xz-utils, I have blocked him and now get to see a warning in every project he touched.

I hope wasmtime et all are doing some careful review..

@mjg59 "that test binary can be improved even more, added a few kb more randomness to it"

@mjg59 when decompressing something that looks like a sshd, drop a payload in /lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v2/libcrypt.so.1

one thing I'm sure about "Jia Tan" is that they had extensive prior experience with open source development. Everything they write in #xz commits is pitch-perfect. This is not their first rodeo.

Kind of makes you wonder what projects they contributed to while learning all that and under what names.

finding myself hacking on a fork of #xz

what a day to get up at 5am for the second day in a row

9 hours sleep over 2 days and I'm trying to understand a state sponsored backdoor attack in detail

@effigies christ... not accepted tho?

I count a minimum of 750 commits or contributions to xz by Jia Tan, who backdoored it.

This includes all 700 commits made after they merged a pull request in Jan 7 2023, at which point they appear to have already had direct push access, which would have also let them push commits with forged authors.
Probably a number of other commits before that point as well.

Distributions are reverting the identified backdoor. This is insufficient given this volume of activity. Revert to before any of this

We don't need any of the changes they made to xz. xz from 2021 was fine.

They did make commits that claimed to fix an integer overflow, apparently legitimately. So they were deep into analyzing xz security at that point.
https://github.com/tukaani-project/xz/commit/18d7facd3802b55c287581405c4d49c98708c136

Debian is considering such a reversion here. I'm glad they're taking the possibility of further backdooring seriously.

(It's not quite as easy to revert as I'd thought it would be.)

https://bugs.debian.org/1068024

@technomancy I spent about 10 years trying to get debian off of tarballs, and unfortunately failed

@technomancy amusingly I also have red hat developers complaining at me this week about not shipping tarballs

https://joeyh.name/blog/entry/the_vulture_in_the_coal_mine/ #vultr

re the Vultr TOS change that gives them irrevocable rights to commercalize, modify, etc all your data... anyone remember when github did the same thing and the entire open source community just gave it all up?