[mu4e must have changed the key bindings for replies, so here is my mail again, this time as a wide reply.]
Giovanni Biscuolo <g...@xelera.eu> writes: > So AFAIU using a fixed "autoreconf -fi" should mitigate the risks of > tampered .m4 macros (and other possibly tampered build configuration > script)? > > IMHO "ignoring" (deleting) pre-built build scripts in Guix > build-system(s) should be considered... or is /already/ so? The gnu-build-system has a bootstrap phase, but it only does something when a configure script does not already exist. We sometimes force it to bootstrap the build system when we patch configure.ac. In previous discussions there were no big objections to always bootstrapping the build system files from autoconf/automake sources. This particular backdoor relied on a number of obfuscations: - binary test data. Nobody ever looks at binaries. - incomprehensibility of autotools output. This one is fundamentally a social problem and easily extends to other complex build systems. In the xz case, the instructions for assembling the shell snippets to inject the backdoor could hide in plain sight, just because configure scripts are expected to be near incomprehensible. They contain no comments, are filled to the brim with portable (lowest common denominator) shell magic, and contain bizarrely named variables. Not using generated output is a good idea anyway and removes the requirement to trust that the release tarballs are faithful derivations from the autotools sources, but given the bland complexity of build system code (whether that's recursive Makefiles, CMake cruft, or the infamous gorilla spit[1] of autotools) I don't see a good way out. [1] https://www.gnu.org/software/autoconf/manual/autoconf-2.65/autoconf.html#History > Given the above observation that <<it is pragmatically impossible [...] > to peer review a tarball prepared in this manner>>, I strongly doubt that > a possible Makefile tampering _in_the_release_tarball_ is easy to peer > review; I'd ask: is it feaseable such an "automated analysis" (see > above) in a dedicated build-system phase? I don't think it's feasible. Since Guix isn't a regular user (the target audience of configure scripts) it has no business depending on generated configure scripts. It should build these from source. > In other words: what if the backdoor was injected directly in the source > code of the *official* release tarball signed with a valid GPG signature > (and obviously with a valid sha256 hash)? A malicious maintainer can sign bad release tarballs. A malicious contributor can push signed commits that contain backdoors in code. > Do upstream developer communities peer review release tarballs or they > "just" peer review the code in the official DVCS? Most do neither. I'd guess that virtually *nobody* reviews tarballs beyond automated tests (like what the GNU maintainers' GNUmakefile / maint.mk does when preparing a release). > Also, in (info "(guix) origin Reference") I see that Guix packages can have a > list of uri(s) for the origin of source code, see xz as an example [7]: > are they intended to be multiple independent sources to be compared in > order to prevent possible tampering or are they "just" alternatives to > be used if the first listed uri is unavailable? They are alternative URLs, much like what the mirror:// URLs do. > If the case is the first, a solution would be to specify multiple > independent release tarballs for each package, so that it would be > harder to copromise two release sources, but that is not something under > Guix control. We have hashes for this purpose. A tarball that was modified since the package definition has been published would have a different hash. This is not a statement about tampering, but only says that our expectations (from the time of packaging) have not been met. > All in all: should we really avoid the "pragmatically impossible to be > peer reviewed" release tarballs? Yes. -- Ricardo
