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.
