Introduction

XZ Utils are a complete C99 implementation of the .xz file format. XZ Utils were originally written for POSIX systems but have been ported to a few non-POSIX systems as well.

The core of the XZ Utils compression code is based on LZMA SDK but it has been modified significantly to be suitable for XZ Utils.

XZ Utils consist of several components:

  • liblzma is a compression library with an API similar to that of zlib.

  • xz is a command line tool with syntax similar to that of gzip.

  • xzdec is a decompression-only tool smaller than the full-featured xz tool.

  • A set of shell scripts (xzgrep, xzdiff, etc.) have been adapted from gzip to ease viewing, grepping, and comparing compressed files.

Documentation

Man pages with keyword indexes:

liblzma API documentation was generated using Doxygen.

Security issues

CVE-2024-3094: liblzma backdoor

XZ Utils 5.6.0 (2024-02-24) and 5.6.1 (2024-03-09) release tarballs contain a backdoor that was inserted by a malicious co-maintainer. It was discovered by Andres Freund and made public on 2024-03-29. The incident is known as CVE-2024-3094.

This is still being investigated. See the XZ Utils backdoor page for more information and also the XZ Utils review notes.

CVE-2022-1271: xzgrep filename handling

CVE-2022-1271 is also known as ZDI-CAN-16587.

Malicious filenames can make xzgrep to write to arbitrary files or (with a GNU sed extension) lead to arbitrary code execution. A patch to fix it was made public on 2022-04-07. The patch applies to 4.999.9beta, 5.0.0 to 5.2.5, 5.3.1alpha, and 5.3.2alpha. Newer XZ Utils releases include an improved fix for the problem.

The vulnerability was discovered by cleemy desu wayo working with Trend Micro Zero Day Initiative.

CVE-2020-22916: A bogus CVE

CVE-2020-22916 is bogus; it’s not a security issue or a bug.

The report had a corrupt .lzma file which uses a tiny 256-byte dictionary. So decompression needs very little memory. The reporter claimed that decompressing it “could cause endless output”.

Both XZ Utils and the long-deprecated LZMA Utils produce 114,881,179 bytes of output from the file before reporting an error. This is not “endless output”. The decompression speed is good too.

Source packages

See the NEWS file for a summary of changes between versions.

The releases have been signed with Lasse Collin’s OpenPGP key.

Stable

XZ Utils 5.2.13, 5.4.7, and 5.6.2 were released on 2024-05-29. The 5.2.13 and 5.4.7 are likely the final releases from the old stable branches.

These releases have a build system issue that prevents building of shared libraries on some systems like mips64. See the patch itself for details. The same patch applies to 5.2.13, 5.4.7, and 5.6.2.

5.6.2 (2024-05-29)

xz-5.6.2.tar.gz

2301 KiB

signature

xz-5.6.2.tar.bz2

1662 KiB

signature

xz-5.6.2.tar.xz

1277 KiB

signature

xz-5213-547-562-libtool.patch

signature

5.4.7 (2024-05-29)

xz-5.4.7.tar.gz

2733 KiB

signature

xz-5.4.7.tar.bz2

2116 KiB

signature

xz-5.4.7.tar.xz

1578 KiB

signature

xz-5213-547-562-libtool.patch

signature

5.2.13 (2024-05-29)

xz-5.2.13.tar.gz

2064 KiB

signature

xz-5.2.13.tar.bz2

1657 KiB

signature

xz-5.2.13.tar.xz

1260 KiB

signature

xz-5213-547-562-libtool.patch

signature

XZ Utils source packages are also available on Sourceforge.

Old releases

Source and binary packages of the old XZ Utils releases are available on a separate page.

Development

The primary Git repository is on GitHub:

git clone https://github.com/tukaani-project/xz

The repository is mirrored (with some delay) to git.tukaani.org as well.

The master branch contains the latest development code.

Maintenance status of the stable branches:

  • v5.6: maintained until 5.8.0 is ready

  • v5.4: critical fixes only

  • v5.2: critical fixes only

  • v5.0: unmaintained

The other branches on GitHub are temporary development branches which also see force pushes. These branches aren’t mirrored to git.tukaani.org.

Building from xz.git

Two multi-platform build systems are supported:

  • The GNU Autotools-based build is old, feature complete, and the most tested. Apart from Windows, DOS, and OpenVMS, the Autotools-based build is the most likely to work on less common or old platforms. Run ./autogen.sh to generate the configure script and other files.

  • CMake-based build became almost feature complete in May 2024 (32-bit x86 assembly code has to be enabled manually as there is no autodetection, and updating translation files isn’t implemented). It should be good to use on common operating systems for which new enough CMake is available. However, it hasn’t received as much testing as the Autotools-based build. See the notes at the top of CMakeLists.txt.

Special cases: OpenVMS and DOS builds use different build systems. See the file INSTALL.

Minimum Autotools and CMake versions

For GNU Autotools, it is recommended to use the latest versions. The minimum versions required are old though:

  • Autoconf 2.69

  • Automake 1.12

  • gettext 0.19.6

  • Libtool 2.4

For the CMake build, version 3.14 or greater is required. However, translation support is disabled with CMake versions older than 3.20. Translation support also requires that GNU gettext-tools are installed.

Optional dependencies

po4a is needed for translated documentation (man pages).

  • Autotools: To build without po4a, pass --no-po4a as the argument to autogen.sh.

  • CMake: Run the shell script po4a/update-po to generate the translated man pages inside the source tree (thus the source tree will have extra files; it won’t stay completely clean). If the translated man pages exist in the source tree, make install will install them if translation support was enabled (ENABLE_NLS).

Doxygen can be used to generate liblzma API documentation in HTML format which make install will also install. Doxygen usage is disabled by default.

  • Autotools: Pass --enable-doxygen as an argument to configure.

  • CMake: Pass -DENABLE_DOXYGEN=ON as an argument to cmake.

Future build system plans

People have wished for Meson support and work on it has been started. If it goes well, it might replace CMake support. Maintaining three build systems doesn’t seem practical.

While dropping Autotools is tempting, there are use cases where Autotools have benefits still:

  • Easier bootstrapping on modern operating systems. muon might make this easier with Meson-based build though.

  • Better support for old or obscure operating systems. As time goes on, these get less and less important though.

Binary packages

Many free software operating systems already provide easy-to-install XZ Utils binaries. It doesn’t make sense to provide links to all those here.

No up-to-date binaries for Windows or DOS are currently available. See the old releases page for old versions.

Supported platforms

Below is an incomplete and somewhat vague (version numbers mostly missing) list of operating systems on which XZ Utils should work. Compiler(s) or toolchains are mentioned in parenthesis. GCC refers to GCC 3 or later. If Clang/LLVM is available for the operating system then it should work too. Additions and corrections are welcome.

  • GNU/Linux (GCC, Clang, ICC, ICX, XL C)

  • GNU/Hurd (GCC)

  • DragonflyBSD

  • FreeBSD

  • MirBSD

  • NetBSD

  • OpenBSD

  • MINIX 3.3.0 and later [1]

  • Haiku

  • SerenityOS

  • AROS and AmigaOS

  • macOS / Mac OS X / Darwin

  • Solaris 10, 11 (GCC, Sun Studio / Oracle Developer Studio) [1]

  • AIX (GCC, XL C) [1]

  • z/OS UNIX System Services (XL C) [1]

  • QNX

  • HP-UX (GCC, HP ANSI C) [2]

  • OpenVMS (HP C compiler) [1]

  • OpenVOS 17 (GCC)

  • Windows 2000 and later (GCC or Clang/LLVM with MinGW-w64, GCC/Cygwin, Visual Studio 2015 or later) [1]

  • DOS e.g. FreeDOS and MS-DOS (GCC/DJGPP) [1]

XZ Utils have or had support for the following operating systems but recent releases might not work anymore. If the latest XZ Utils don’t work, try XZ Utils 5.4.7 or an even older release. Support for obsolete operating systems and versions might be retained or restored if it is easy to do.

  • Solaris 9 and older [3]

  • IRIX (MIPSpro) [1]

  • Tru64 (GCC, Compaq C compiler) [4]

  • SCO OpenServer 5 (GCC 3.4.6, 4.2.4) [5]

  • Windows 95/98/98SE/ME, NT4, Interix (pre-W2k support was disabled after XZ Utils 5.4.x)

  • OS/2, eComStation (GCC)

Licensing

From the version 5.5.2beta onwards, the core components of XZ Utils are under the BSD Zero Clause License (0BSD). The earlier versions that were released as public domain obviously remain in the public domain.

Some parts of XZ Utils (for example, scripts from GNU gzip and some build system files) are under different free software licenses such as GNU LGPLv2.1, GNU GPLv2, or GNU GPLv3.

See the file COPYING for more details.


1. See also the platform-specific notes in the INSTALL file.
2. 2010-09-22: It was reported that HP ANSI C compiler crashes when compiling XZ Utils on PA-RISC. On Itanium there were no problems.
3. On Solaris 8 and 9 one may need to pass ac_cv_prog_cc_c99= to configure if using Sun Studio.
4. With the native compiler CC=cc one may need to pass ac_cv_prog_cc_c99= to configure.
5. On SCO OpenServer 5, use --disable-threads when running configure.