bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sr #111048] Add a syntax check to code snippets


From: Po Lu
Subject: Re: [sr #111048] Add a syntax check to code snippets
Date: Tue, 09 Apr 2024 09:20:33 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

Fabrice BAUZAC-STEHLY <INVALID.NOREPLY@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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]