In case anyone didn't hear about it, xz versions 5.6.0 and 5.6.1 definitely have a backdoor [1], CVE-2024-3094, most likely by a state actor, that could have let a specific crackers' group have ssh access to many of the most secure servers around the world - x86_64 Debian servers - if it hadn't been discovered in time [2]. The xz community is still working on a full audit of possibly affected code on irc #tukaani on LiberaChat, and that will take some time.

Unfortunately, Jia Tan's contributions are included as early as version 5.2.6 [3]. S/he happened to get involved around the same time that I discovered the RHEL/CentOS 7 ill patch.

Version 5.2.5 is completely clean of Jia Tan's contributions, but will fail on RHEL/CentOS 7, which is a problem for Maneage reproducibility.

Maneage commit 4318670 has

grep xz reproduce/software/config/versions.conf
xz-version = 5.2.5

So I recommend that for the moment we only move forward to commit 2581607 [4], which is one commit beyond 7123dfa5 (by Mohammad), i.e. this is the fix to 5.2.5 as recommended by Lasse -  until he had time to do a full fix. (This overrides my Sat 10 Sep 2022 05:47:23 PM UTC, Tue 20 Sep 2022 08:39:33 PM UTC and Sat 11 Mar 2023 09:00:45 PM UTC recommendations: ignore them.)

[1] https://tukaani.org/xz-backdoor

[2] https://en.wikipedia.org/wiki/XZ_Utils_backdoor

[3] https://salsa.debian.org/debian/xz-utils/-/commits/v5.2.6/?ref_type=tags

[4] https://codeberg.org/boud/maneage_dev/commit/2581607b21b2d4011f6669d0420aaa370bb186dc

The time scale for xz-5.2.7 to be released should be a month or so; possbly shorter. On Maneage time scales, that's short :).

Anyone impatient, or worried about the CentOS 7 bug, can look at this patch without waiting:

https://git.tukaani.org/?p=xz.git;a=commitdiff;h=31d80c6b261b24220776dfaeb8a04f80f80e0a24

While it is useful for xz to protect against the CentOS 7 mess, in principle, Maneage should not have detected the error, since we build both xz and cmake.

However, commit 2a3304cfb of Maneage from Dec 2018 by Mohammad [1] changes from

-       ./bootstrap --prefix=$(idir) && make && make install && \

to

+       ./bootstrap --prefix=$(idir) --system-curl --system-zlib \
+                    --system-bzip2 --system-liblzma &&          \

in the high-level.mk rule for building cmake.

This makes cmake dependent on the host system, and helped to detect the xz problem on CentOS 7. However, detecting bugs is not our primary aim :).

Is there any good reason for building cmake on the host system curl, zlib, bzip2, and liblzma?

If not, then I propose to remove all four of these --system-X options from the cmake build rule.


[1] http://git.maneage.org/project.git/commit/?id=2a3304cfb832d2f9548bb869f5a44a3412a1c3f9

The fix in https://savannah.nongnu.org/task/?16244 works for me. I think we could leave this bug open for a while though, to see if xz upstream finally comes up with any comments - e.g. let's say another month, since the main xz developer is probably on holidays.

But I've downgraded the bug status from 5-Blocker to 3-Normal, since we seem to have what is the best recommended fix - so far.

See the #14991 github/easybuilders thread, which points to a pdf by Pat Riehecky [1]. It seems like the bug is not the fault of cmake in CentOS7, it's rather related to pthread/glibc in CentOS7. Our long-term solution is task 15390: install our own glibc [2] :).

Someone who understands pthread/glibc better than me can decide whether it's better to hack pthread/glibc for the CentOS7 case, or rather to stick to the xz workaround.

[1] https://lss.fnal.gov/archive/2021/slides/fermilab-slides-21-020-scd.pdf
[2] https://savannah.nongnu.org/task/?15390

SYSTEM:

Linux 3.10.0-1160.36.2.el7.x86_64 #1 SMP Wed Jul 21 11:57:15 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

CentOS Linux release 7.9.2009 (Core)

initial gcc on the host: 10.2.0

env variables set in startup script sent to slurm:

LD_LIBRARY_PATH=/opt/exp_soft/local/generic/gcc/10.2.0/lib/gcc/x86_64-pc-linux-gnu/10.2.0:/opt/exp_soft/local/generic/gcc/10.2.0/lib64:/opt/exp_soft/local/generic/gcc/10.2.0/lib
LDFLAGS=-L/opt/exp_soft/local/generic/gcc/10.2.0/lib/gcc/x86_64-pc-linux-gnu/10.2.0 -L/opt/exp_soft/local/generic/gcc/10.2.0/lib64 -L/opt/exp_soft/local/generic/gcc/10.2.0/lib
CFLAGS=-I/opt/exp_soft/local/generic/gcc/10.2.0/include

maneage source: maneage-27ff6f7-git.bundle
https://git.maneage.org/project.git/commit/?id=27ff6f7d57ebdd3d3051040b982c1976f990c6e1


KEY LINES OF BUG:

...
make[3]: Leaving directory '/dev/shm/24623915-maneage-27ff6f7-git-boud/cmake-3.21.4'
[100%] Built target pseudo_cpplint
make[3]: Entering directory '/dev/shm/24623915-maneage-27ff6f7-git-boud/cmake-3.21.4'
Consolidate compiler generated dependencies of target pseudo_tidy
make[3]: Leaving directory '/dev/shm/24623915-maneage-27ff6f7-git-boud/cmake-3.21.4'
[100%] Built target pseudo_tidy
make[3]: Entering directory '/dev/shm/24623915-maneage-27ff6f7-git-boud/cmake-3.21.4'
Consolidate compiler generated dependencies of target pseudo_iwyu
make[3]: Leaving directory '/dev/shm/24623915-maneage-27ff6f7-git-boud/cmake-3.21.4'
[100%] Built target pseudo_iwyu
make[3]: Entering directory '/dev/shm/24623915-maneage-27ff6f7-git-boud/cmake-3.21.4'
Consolidate compiler generated dependencies of target foo
make[3]: Leaving directory '/dev/shm/24623915-maneage-27ff6f7-git-boud/cmake-3.21.4'
[100%] Built target foo
make[2]: Leaving directory '/dev/shm/24623915-maneage-27ff6f7-git-boud/cmake-3.21.4'
Install the project...
bin/cmake: /BUILD/software/installed/lib/liblzma.so.5: version `XZ_5.2.2' not found (required by bin/cmake)
bin/cmake: /BUILD/software/installed/lib/liblzma.so.5: version `XZ_5.1.2alpha' not found (required by bin/cmake)
make[1]: *** [Makefile:144: install] Error 1
make[1]: Leaving directory '/dev/shm/24623915-maneage-27ff6f7-git-boud/cmake-3.21.4'

FULL LOG:
full log file


CLUES:
It seems like this is a known bug for Redhat systems [1][2] since 2017.
This gives at least two puzzles:

(1) Why hasn't the fix been upstreamed to xz? (hypothesis:
because this is a one-person email-or-irc-bug-report maintained program; see
MAINTAINABILITY below)

(2) Why does maneage compiling cmake have a problem with the lzma
library api on a redhat machine but not on another machine, since
high-level software should be isolated from OS-dependent library
apis like this?

On a machine on which a merge with 27ff6f7 compiled successfully,

$ ldd .local/bin/cmake |grep lzma
liblzma.so.5 => /BUILD/software/installed/lib/liblzma.so.5 (0x00XXXXXXXXXXXXXX)

It is also possible that the patch proposed in [2] itself creates a
bug on redhat systems [3], as of a report in 2022, per Easybuild [4]
users/developers.

[1] https://stackoverflow.com/questions/47633870/rpm-lib64-liblzma-so-5-version-xz-5-1-2alpha-not-found-required-by-lib-li
[2] https://github.com/easybuilders/easybuild-easyconfigs/issues/4036
[3] https://github.com/easybuilders/easybuild-easyconfigs/issues/14991
[4] https://github.com/easybuilders/easybuild-easyconfigs

The relation between xz and lzma is not clear to me - understanding this may
help for finding a portable, safe solution.


MAINTAINABILITY of xz:

The [https://git.tukaani.org/?p=xz.git;a=blob_plain;f=README;hb=HEAD
README] file of xz says "Report your bug via email or IRC (see
Contact information below)." This means that if the main developer
is busy or ill, the community cannot fix the bugs without creating
its own fork, e.g. on a git repository.