4 ms·

Also, I know what git, configure, and make are supposed to do when invoked. I have no idea what piping a random script to sh is supposed to do without reading i

Also, I know what git, configure, and make are supposed to do when invoked. I have no idea what piping a random script to sh is supposed to do without reading it.

notacoward 7y ago
You might be surprised. As the OP mentions, configure scripts could contain literally anything. Ditto makefiles. If you're not reading them, you really have no idea what they might do. It's a little harder to embed something awful in git, but with hooks etc. it's not impossible. So when you do "git clone" and "configure" and "make" you're just as subject to vulnerabilities from file replacement or DNS hijacking, and there are just as many opportunities for something bad to happen as if you had piped curl through bash. This is why checking signatures is the most important part of code distribution. It doesn't solve every problem, but it solves most. At least then you know whose code you're getting, and that they attest to the code's validity (including safety). Maybe they're wrong or maybe they're not as good as you thought they were, but it's still a big improvement.
- actionowl 7y ago
  If we ignore the potential security issues with either approach for a moment and assume for the sake of argument that neither is more risky than the other I "might be surprised" by the behavior of running `./configure` or `make install` but I will almost always be surprised by the behavior downloading and running a random shell script. I prefer a package over either case, but lacking a package I'd prefer to use something that has some expectations of how it should behave. As a packager I find that software with a Makefile, CMakeLists.txt, or a configure script is likely to be easier to package than something that just provides a shell script. Those might still need to be patched or tweaked but there's an expectation that it's going to try to behave a certain way.

Also, I know what git, configure, and make are supposed to do when invoked. I have no idea what piping a random script to sh is supposed to do without reading it.

notacoward 7y ago

You might be surprised. As the OP mentions, configure scripts could contain literally anything. Ditto makefiles. If you're not reading them, you really have no idea what they might do. It's a little harder to embed something awful in git, but with hooks etc. it's not impossible. So when you do "git clone" and "configure" and "make" you're just as subject to vulnerabilities from file replacement or DNS hijacking, and there are just as many opportunities for something bad to happen as if you had piped curl through bash. This is why checking signatures is the most important part of code distribution. It doesn't solve every problem, but it solves most. At least then you know whose code you're getting, and that they attest to the code's validity (including safety). Maybe they're wrong or maybe they're not as good as you thought they were, but it's still a big improvement.

actionowl 7y ago
If we ignore the potential security issues with either approach for a moment and assume for the sake of argument that neither is more risky than the other I "might be surprised" by the behavior of running `./configure` or `make install` but I will almost always be surprised by the behavior downloading and running a random shell script. I prefer a package over either case, but lacking a package I'd prefer to use something that has some expectations of how it should behave. As a packager I find that software with a Makefile, CMakeLists.txt, or a configure script is likely to be easier to package than something that just provides a shell script. Those might still need to be patched or tweaked but there's an expectation that it's going to try to behave a certain way.