xz-5.6.3

[Xi Ruoyao]

New patch version.

[Xi Ruoyao]

5.6.3 (2024-10-01)

IMPORTANT: This includes a Windows-specific security fix to the command line tools. liblzma isn't affected by this issue.

• liblzma:
  • Fix x86-64 inline assembly compatibility with GNU Binutils older than 2.27.
  • Fix the build with GCC 4.2 on OpenBSD/sparc64.
• xzdec: Display an error instead of failing silently if the unsupported option -M is specified.
• lzmainfo: Fix integer overflows when rounding the dictionary and uncompressed sizes to the nearest mebibyte.
• Windows (except Cygwin and MSYS2): Add an application manifest to xz, xzdec, lzmadec, and lzmainfo executables:
  • Declare them compatible with Vista/7/8/8.1/10/11. This way the programs won't needlessly use Operating System Context of Vista when running on later Windows versions. This setting doesn't mean that the executables cannot run on even older versions if otherwise built that way.
  • Declare them as UAC-compliant. MSVC added this by default already but it wasn't done with MinGW-w64, at least not with all toolchain variants.
  • Declare them long path aware. This makes long path names work on Windows 10 and 11 if the feature has been enabled in the Windows registry.
  • Use the UTF-8 code page on Windows 10 version 1903 and later.
    • Now command line tools can access files whose names contain characters that don't exist in the current legacy code page.
    • The options --files and --files0 now expect file lists to be in UTF-8 instead of the legacy code page.
    • This fixes a security issue: If a command line contains Unicode characters (for example, filenames) that don't exist in the current legacy code page, the characters are converted to similar-looking characters with best-fit mapping. Some best-fit mappings result in ASCII characters that change the meaning of the command line, which can be exploited with malicious filenames to do argument injection or directory traversal attacks. UTF-8 avoids best-fit mappings and thus fixes the issue.

Forcing the process code page to UTF-8 is possible only on Windows 10 version 1903 and later. The command line tools remain vulnerable if used on an old older version of Windows.

This issue was discovered by Orange Tsai and splitline from DEVCORE Research Team.

A related smaller issue remains: Windows filenames may contain unpaired surrogates (invalid UTF-16). These are converted to the replacement character U+FFFD in the UTF-8 code page. Thus, filenames with different unpaired surrogates appear identical and aren't distinguishable from filenames that contain the actual replacement character U+FFFD.

• When building with MinGW-w64, it is recommended to use UCRT version instead of the old MSVCRT. For example, non-ASCII characters from filenames won't print correctly in messages to console with MSVCRT with the UTF-8 code page (a cosmetic issue). liblzma-only builds are still fine with MSVCRT.

• Cygwin and MSYS2 process command line options differently and the above issues don't exist. There is no need to replace the default application manifest on Cygwin and MSYS2.

• Autotools-based build:
  • Fix feature checks with link-time optimization (-flto).
  • Solaris: Fix a compatibility issue in version.sh. It matters if one wants to regenerate configure by running autoconf.
• CMake:
  • Use paths relative to ${prefix} in liblzma.pc when possible. This is done only with CMake >= 3.20.
  • MSVC: Install liblzma.pc as it can be useful with MSVC too.
  • Windows: Fix liblzma filename prefix, for example:
    • Cygwin: The DLL was incorrectly named liblzma-5.dll. Now it is cyglzma-5.dll.
    • MSVC: Rename import library from liblzma.lib to lzma.lib while keeping liblzma.dll name as is. This helps with "pkgconf --msvc-syntax --libs liblzma" because it mungles "-llzma" in liblzma.pc to "lzma.lib".
    • MinGW-w64: No changes.
  • Windows: Use the correct resource file for lzmadec.exe. Previously the resource file for xzdec.exe was used for both. Autotools-based build isn't affected.
  • Prefer a C11 compiler over a C99 compiler but accept both.
  • Link Threads::Threads against liblzma using PRIVATE so that -pthread and such flags won't unnecessarily get included in the usage requirements of shared liblzma. That is, target_link_libraries(foo PRIVATE liblzma::liblzma) no longer adds -pthread if using POSIX threads and linking against shared liblzma. The threading flags are still added if linking against static liblzma.
• Updated translations: Catalan, Chinese (simplified), and Brazilian Portuguese.

[Bruce Dubbs]

Fixed at commit 52104e05f0 :

    Update to iana-etc-20241015.
    Update to vim-9.1.0813.
    Update to xz-5.6.3.
    Update to sysvinit-3.11.
    Update to setuptools-75.2.0.
    Update to Python3-3.13.0.
    Update to openssl-3.4.0.
    Update to meson-1.6.0.
    Update to markupsafe-3.0.2.
    Update to linux-6.11.5.
    Update to less-668.
    Update to elfutils-0.192.