To include in the nixpkgs package repository used in the NixOS distribution, a mode of reproducible builds has been proposed, allowing for the detection of instances of backdoor insertion into the code, reminiscent of the incident with the XZ project. The presented protection method enables the detection of modifications in source code archives of the release that are absent in the code repositories.
The essence of the method is that the source code of the new version of the application is built twice — first from the code loaded from the git repository, and second from the code distributed in ready-made archives. If the resulting binary files differ, it raises suspicions of hidden modifications in the repository or in the archive file containing the code.
Recall that in the case of the XZ project, the code repository did not contain any suspicious changes. The components forming the backdoor were delivered within files used in the test suite for verifying the unarchiver's correct operation. The backdoor was activated at the build system level, while the source code of XZ matched the code from the repository. The triggering backdoor m4 macros for the Automake toolkit were included only in the finished archive of the code and were absent in the repository.
The backdoor in XZ was implanted by an attacker who obtained maintainer status in the project. The backdoor insertion went unnoticed immediately because distributions mainly build packages by loading code from ready-made archives, as a single checksum can be used for file integrity verification and mirrors can be utilized when loading code for builds. The primary focus during code verification is on analyzing the repository contents, so non-obvious differences in the archives may not always be detected immediately.
To simplify the verification of archive files and repository snapshots corresponding to releases, some open projects, such as PostgreSQL, have introduced a system of repeatable archive generation. In this case, a toolkit is provided that allows you to independently create your archive from the code, fully matching the downloadable archive available. If the independently created archive differs from the archive provided by the main project, there is a compromise of the repository or reference archive.
The problem is that this method is only practiced in certain cases, while many projects continue to include additional artifacts in the archives that are not present in the main repository, such as man pages, documentation, examples, distribution package creation scripts, and additional build files. This mainly occurs due to historical reasons and the peculiarities of the release formation processes. A simple compliance check between the repository contents and the archive is not suitable in this case.
As a solution, it has been proposed to collect release binaries both from the repository (for example, using the automatically generated GitHub archive for the release tag) and from the archive prepared by the maintainer, then comparing the results. As an experiment, this type of check is currently proposed only for the 'xz' package. If the experiment turns out successful, the checks are planned to be used in other packages in nixpkgs.
Source: opennet.ru
