Fabrice BAUZAC-STEHLY <invalid.nore...@gnu.org> writes: > Follow-up Comment #3, sr #111048 (group autoconf): > > I agree, it's not so easy. > > On CMake side, I think they are considering adding an "escape hatch" that > would not go unnoticed either. > > For Autoconf, maybe we could add a separate macro (with a very explicit name) > for syntax checks like "case 0 ... 5". A malicious contributor would have a > harder time explaining why they would create a syntax check for checking the > availability of a system feature like landlock, as was the case with XZ > Utils. > https://www.man7.org/linux/man-pages/man7/landlock.7.html > > My 2 cents...
In Autoconf scripts, it's frequently the case that the absence of a feature is signaled by arranging for a syntax error to be compiled if certain preprocessor macros be undefined. Take Gnulib's macro for detecting Clang: # AC_CHECK_DECL executed conditionally. Therefore append the extra tests # to AC_PROG_CC. AC_DEFUN([gl_COMPILER_CLANG], [ dnl AC_REQUIRE([AC_PROG_CC]) AC_CACHE_CHECK([whether the compiler is clang], [gl_cv_compiler_clang], [dnl Use _AC_COMPILE_IFELSE instead of AC_EGREP_CPP, to avoid error dnl "circular dependency of AC_LANG_COMPILER(C)" if AC_PROG_CC has dnl not yet been invoked. _AC_COMPILE_IFELSE( [AC_LANG_PROGRAM([[ #ifdef __clang__ barfbarf #endif ]],[[]]) ], [gl_cv_compiler_clang=no], [gl_cv_compiler_clang=yes]) ]) ]) I think this practice was historically more widespread than today, but nevertheless syntax errors are perfectly legitimate constructs in any build-time feature test, and demanding that their existence be indicated by a special macro would break numerous existing Autoconf scripts while not producing any appreciable improvement in security. Doing so would be throwing the baby out with the bathwater, and a distraction from the plenty of other venues a malicious maintainer could exploit to conceal code, of which mending this specific instance would penalize Autoconf users to a much greater degree than malefactors, while also setting a precedent for this "whack-a-mole" approach to security, which, fueled by paranoia rather than concrete consideration, is not likely to be effective before an adversary in the position of trust enjoyed by package maintainers.