1. 11
  1.  

  2. 6

    There have been trojans found in ./configure scripts (look it up), which is why I regularly advocate for abandoning autotools. And the response I usually get is “Let’s not talk about that, please.” A plaintext blob is still a blob.

    1. 4

      Shouldn’t the solution be sandboxing the build? Instead of … what are you proposing instead of autotools that could eliminate the possibilities of trojans in the build process exactly?

      1. 4

        I absolutely love BSD Makefile syntax. A project I maintain is a good example of a simple BSD Makefile. For reference, I’ve posted it below.

        SHLIB=	pushover
        SHLIB_MAJOR=	0
        SRCS=	libpushover.c sanity.c
        INCS=	libpushover.h
        
        CFLAGS+=	-I${.CURDIR} -I/usr/local/include
        LDFLAGS+=	-L/usr/local/lib
        
        LDADD=		-lcurl -lsbuf
        
        .if defined(PREFIX)
        LIBDIR=		${PREFIX}/lib
        INCLUDEDIR=	${PREFIX}/include
        .endif
        
        .include <bsd.lib.mk>
        
        1. 1

          Which is fine if you are happy to depend on bsd.lib.mk existing, but if you’ve ever looked inside that file then you’ll be absolutely horrified if anyone claims it is simple or readable.

          1. 1

            I’ve hacked on bsd.lib.mk, wasn’t difficult for me.

          2. 1

            I meant to reply to the comment above yours. Sorry!

            1. 1

              I usually try to make my makefiles OS-agnostic by trying to adhere to the POSIX makefile spec (w/o the GNU or BSD extensions).
              But the neatness and brevity of BSD makefiles astounds me.

              1. 1

                Yeah. I generally don’t need to worry about supporting non-BSD systems.

            2. 1

              Sandboxing could prevent a trojaned shellblob from harming the build host, but it wouldn’t prevent it from tampering with the build product.

              One point worth making is that a configure.ac or configure.in is amenable to auditing, so projects that use autotools without distributing a prerolled ./configure shellblob don’t have this problem. It’s bad practice to check ./configure into git, so a lot of people don’t do that. Nowadays, a source tarball that is essentially output from git archive is really common. So it’s a point less worth arguing as time goes by.

              1. 1

                Sandboxing could prevent a trojaned shellblob from harming the build host, but it wouldn’t prevent it from tampering with the build product.

                That’s not a particularly interesting threat model. Anyone with the ability to trojan a configure script that you run also has the ability to trojan any of the source files in the build that the configure script is generating.

                1. 1

                  You “regularly advocate for abandoning autotools”, and I was trying to ask what you propose for people to use instead that would be safe from trojans.

                  1. 1

                    I don’t have a one size fits all solution to advocate. CMake is okay; I’ve had some experience with it. Meson looks like it might be interesting.

                    In a lot of cases a makefile and a judicious use of pkg-config is good enough.

                    1. 1

                      Nothing is truly safe, but the generated configure scripts is usually well over 10,000 lines of hard to read shell script, and few people will look at that, if any. It’s incredibly easy to hide something in there, even for larger projects with quite a few contributors. You can try to hide something in the main code or somewhere else too, but it’s much more likely to be noticed.