4 ms·

> 1a. As a consequence of (1) autogenerated artifacts should always be committed. Or… just have downstream users run autotools as part of the build?

hk__2 3y ago
> Or… just have downstream users run autotools as part of the build? See point 3: > 3. A corollary of (1) and (2) is that autotools is bad and the autotools culture is bad.
- jorams 3y ago
  Whether it's autotools or not is not very relevant to point 1a. I'm also confused why point 1 leads to 1a, and not to the opposite of 1a. Source distribution tarballs should not contain code different from what's in the source repository. They should not contain automatically generated artifacts, since those should not be in the repository, since they are by definition not the source, but output of some kind of build process. Having the automatically generated configure script in the repository would have made it slightly easier to spot the backdoor if anyone took the time to read the committed configure script, but if it's already in the repository most people will just take that for granted, not run whatever process generates it, and not notice that it's not actually the output of said process.
  - sokoloff 3y ago
    That very last point seems like something that's fairly amenable to automation, though. (Then, that automation can be attacked, but that seems like one more [fairly independent] layer that must be bypassed to execute one of these attacks.)
  - simiones 3y ago
    I think the point is that all of the code which will get compiled to produce the final binary should be in the repo, and so any generated code that affects the final binary should be in the repo. The use of autotools or other similar tools, ones that are supposed to generate code on the fly on the final user's machine, make this requirement essentially impossible.
    - Nullabillity 3y ago
      Your compiler also falls under that bucket, though.
      - sokoloff 3y ago
        Reference the old Ken Thompson compiler hack to provide a backdoor for Unix logins: https://wiki.c2.com/?TheKenThompsonHack https://wiki.c2.com/?TheKenThompsonHack
      - simiones 3y ago
        In this case, we're talking about someone distributing source code for others to compile, so that is out of scope.
- marcosdumay 3y ago
  Part of the bad in autotools culture is to run it when creating the release so people don't need to run before building. Letting people run autotools would completely avoid this one hack. But well, you have a point in that most of what makes autotools bad is that you can't expect your userbase to learn how to use it.

hk__2 3y ago

> Or… just have downstream users run autotools as part of the build? See point 3: > 3. A corollary of (1) and (2) is that autotools is bad and the autotools culture is bad.

jorams 3y ago
Whether it's autotools or not is not very relevant to point 1a. I'm also confused why point 1 leads to 1a, and not to the opposite of 1a. Source distribution tarballs should not contain code different from what's in the source repository. They should not contain automatically generated artifacts, since those should not be in the repository, since they are by definition not the source, but output of some kind of build process. Having the automatically generated configure script in the repository would have made it slightly easier to spot the backdoor if anyone took the time to read the committed configure script, but if it's already in the repository most people will just take that for granted, not run whatever process generates it, and not notice that it's not actually the output of said process.
- sokoloff 3y ago
  That very last point seems like something that's fairly amenable to automation, though. (Then, that automation can be attacked, but that seems like one more [fairly independent] layer that must be bypassed to execute one of these attacks.)
- simiones 3y ago
  I think the point is that all of the code which will get compiled to produce the final binary should be in the repo, and so any generated code that affects the final binary should be in the repo. The use of autotools or other similar tools, ones that are supposed to generate code on the fly on the final user's machine, make this requirement essentially impossible.
  - Nullabillity 3y ago
    Your compiler also falls under that bucket, though.
    - sokoloff 3y ago
      Reference the old Ken Thompson compiler hack to provide a backdoor for Unix logins: https://wiki.c2.com/?TheKenThompsonHack https://wiki.c2.com/?TheKenThompsonHack
    - simiones 3y ago
      In this case, we're talking about someone distributing source code for others to compile, so that is out of scope.
marcosdumay 3y ago
Part of the bad in autotools culture is to run it when creating the release so people don't need to run before building. Letting people run autotools would completely avoid this one hack. But well, you have a point in that most of what makes autotools bad is that you can't expect your userbase to learn how to use it.