4 ms·

The alternative is: 1. get tarball 2. do full code audit 3. run code However, almost no one will do step 2, so running code piped from wget is effectively e

The alternative is: 1. get tarball 2. do full code audit 3. run code However, almost no one will do step 2, so running code piped from wget is effectively equivalent with doing step 1 and 3. https provides some level of security, but a determined attacker can make sure you don't get warnings from their MITM attack, which gets us back to having to do step 2.

e12e 13y ago
No. The alternative is to provide a gpg signature of the shell script, and instruct new users to verify the signature, before running the script. The script can then embed signature checks for any downloads. The point isn't to make sure "everything is secure", the point is to avoid terrible advice on the fourth line of the documentation. Another (IMHO not as good) alternative is to simply distribute the script over ssl. A third alternative is for the instructions to show how to first get the file, then check that it is the right file -- but that implies that the reader is qualified to audit the shell script. That's a lot easier said than done. A signature would go a long way to allow the person installing to simply trust the salt project -- without a signature or an ssl distribution point, it doesn't help to trust the salt project: you have no idea what is being piped into the root shell. And it doesn't fill me with confidence when the project advocates doing this -- that leads me to not trust the rest of the code as much, either. As other has pointed out -- distribution via apt etc is also good -- as indicated in the platform specific instructions -- but the documentation lists the apt-platforms among those where the script has been tested.
- andreasvc 13y ago
  Yes SSL or GPG is nice and provides some level of security, but think of the more fundamental problem: you're installing new software from a group of people you probably don't know, it's going to be a leap of faith either way. What you talk about are technical measures that in no way address the social problem of establishing trust in the people making those signatures.
  - e12e 13y ago
    You're missing my point. Even if I trust saltstack, I can't trust whatever comes down over an http link. If they'd signed it (with gpg or ssl) -- then I could choose to trust the code. I'm more than ready (perhaps foolishly) to trust the code from some random group of people -- but I need to be able to trust that code -- not whatever comes down off a possibly spoofed http link. Without signatures of some kind, there can't be any trust. It doesn't matter if I trust Debian to release a good distribution if I have no way to know if the software I'm installing is from Debian.

e12e 13y ago

No. The alternative is to provide a gpg signature of the shell script, and instruct new users to verify the signature, before running the script. The script can then embed signature checks for any downloads. The point isn't to make sure "everything is secure", the point is to avoid terrible advice on the fourth line of the documentation. Another (IMHO not as good) alternative is to simply distribute the script over ssl. A third alternative is for the instructions to show how to first get the file, then check that it is the right file -- but that implies that the reader is qualified to audit the shell script. That's a lot easier said than done. A signature would go a long way to allow the person installing to simply trust the salt project -- without a signature or an ssl distribution point, it doesn't help to trust the salt project: you have no idea what is being piped into the root shell. And it doesn't fill me with confidence when the project advocates doing this -- that leads me to not trust the rest of the code as much, either. As other has pointed out -- distribution via apt etc is also good -- as indicated in the platform specific instructions -- but the documentation lists the apt-platforms among those where the script has been tested.

andreasvc 13y ago
Yes SSL or GPG is nice and provides some level of security, but think of the more fundamental problem: you're installing new software from a group of people you probably don't know, it's going to be a leap of faith either way. What you talk about are technical measures that in no way address the social problem of establishing trust in the people making those signatures.
- e12e 13y ago
  You're missing my point. Even if I trust saltstack, I can't trust whatever comes down over an http link. If they'd signed it (with gpg or ssl) -- then I could choose to trust the code. I'm more than ready (perhaps foolishly) to trust the code from some random group of people -- but I need to be able to trust that code -- not whatever comes down off a possibly spoofed http link. Without signatures of some kind, there can't be any trust. It doesn't matter if I trust Debian to release a good distribution if I have no way to know if the software I'm installing is from Debian.