Pack
xz
Pack | xz | |
---|---|---|
1 | 25 | |
234 | 160 | |
10.7% | - | |
6.0 | 9.7 | |
about 2 months ago | about 2 months ago | |
Pascal | C | |
Apache License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Pack
-
Backdoor in upstream xz/liblzma leading to SSH server compromise
The `pack`[0] compression utility that reached the HN front page the other day[1] is setting off my alarm bells right now. (It was at the time too, but now doubly so)
It's written in Pascal, and the only (semi-)documented way to build it yourself is to use a graphical IDE, and pull in pre-compiled library binaries (stored in the git repo of a dependency which afaict Pack is the only dependent of - appears to be maintained by the same pseudonymous author but from a different account).
I've opened an issue[2] outlining my concerns. I'm certainly not accusing them of having backdoored binaries, but if I was setting up a project to be deliberately backdoorable, it'd look a lot like this.
[0] https://pack.ac/
[1] https://news.ycombinator.com/item?id=39793805
[2] https://github.com/PackOrganization/Pack/issues/10
xz
-
XZ backdoor story – Initial analysis
Very funny. This one:
https://github.com/tukaani-project/xz/commits?author=thesame...
- Xz: Update maintainer and author info. The other maintainer suddenly disappeared
- Thanks Andres Freud
- The xz-utils backdoor has been removed
-
The xz sshd backdoor rabbithole goes quite a bit deeper
> The payload of the 'hack' contains fairly easy ways for the xz hackers to update the payload. They actually used it to remove a real issue where their hackery causes issues with valgrind that might lead to discovering it, and they also used it to release 5.6.1 which rewrites significant chunks;
The valgrind fix in 5.6.1 overwrites the same test files used in 5.6.0 instead of using the injection code's extension hooks. This is done with what should have been a highly suspicious commit: https://github.com/tukaani-project/xz/commit/6e636819e8f0703... - this replaces "random" test files with other "random" test files. The state reson is questionable to begin but not including the seed used when the the purpoted reason was to be able to re-create the files in the future is highly suspicous. This should have raised red flags bug no one was watching. I'd say this is another part of the operation that was much more sloppy than it needed to be.
-
Timeline of the xz open source attack
In https://archive.softwareheritage.org/browse/revision/e446ab7...
-
GitHub Disabled the Xz Repo
You're right, but maybe because there's nothing to see : https://github.com/tukaani-project/xz
- Xz Repository Censored by GitHub
- Backdoor in upstream xz/liblzma leading to SSH server compromise
- The Return of the Frame Pointers
What are some alternatives?
rust1 - rust1
wasmtime - A fast and secure runtime for WebAssembly
tukaani-project
libarchive - Multi-format archive and compression library
stencil-golang - Template repository for Golang applications
Folly - An open-source C++ library developed and used at Facebook.
freedesktop-sdk
systemd - The systemd System and Service Manager
STest - Unit testing framework for C/C++. Easy to use by simply dropping stest.c and stest.h into your project!
nixpkgs - Nix Packages collection & NixOS