Fabrice BAUZAC-STEHLY <[email protected]> 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.
