lbzip2

While you are saying that it is utterly unrelated, I'll respond with "that not only related, this is a root cause of current situation". We have a single massively used implementation (also known as reference), which does not even follow xz format specification. It is autohell-based, which allowed m4 injection. In other places it is CMake-based, but uses autohell-based code, inserting hidden dots where they could just use https://cmake.org/cmake/help/latest/module/CheckSymbolExists... "Poor design" is still there, as a core of library. It is as cool, 64-bit square roots and 128-bit divides in Bcachefs[1] It is as cool as lbzip2[2] with their: (((0xffffaa50 >> ((as < 0x20 ? as : (as >> 4)) & 0x1e)) & 0x3) + (as < 0x20 ? 1 : 5)) Spoiler: this lbzip2 code produces corrupted files in some cases, should we care if it is a backdoor? Or as us

The website change reminds me a bit of lbzip2.org https://github.com/kjn/lbzip2/issues/26#issuecomment-1582645... Although, at the moment, it only seems to be spam. The last commit was 6 years ago, so I guess that's better than a maintainer change...