3 ms·

Good point. Download the script, read it, add it as a function in your bashrc if you trust it.

fit2rule 11y ago
For example, in this case any cert you blindly create with the example will have you located in Paris, France, which may not be accurate. So, never blindly pipe the web into your bash, kids.
- digitalsushi 11y ago
  You know, I've struggled with this concept. I agree that we shouldn't pipe a URL into a bash script without knowing what it is. But an unsigned software repository that calls post install scripts seems just as absolutely easy to modify, and we see those regularly. My software is most easily installed with a piped bash script. In the script contents, I try to explain what's going on. I also at the top indicate that you shouldn't just trust what I am telling you. And then in the documentation, where you are told how to run the script, I tell you to be cautious there as well. (The script just installs the repository, and from there it's all signed and delivered over https). I could never get over how easy it would be to whitewash a bash script with an rpm just to get some psychological credibility. If it's not signed and/or delivered over https, it's completely hackable. That first step of trust, how?
  - lmm 11y ago
    People who are serious about their security run something like Debian and only install from the official repositories, where all packages are signed with GPG and all package maintainers must be part of the web of trust (i.e. have had their identity vouched for by at least one other Debian maintainer). Of course you have to make sure the original install is trustworthy; all you can really do for that is compare the .iso checksum on several different machines. If all those machines are compromised (or there's a hardware-level compromise of your machine) then you're doomed, but that at least makes attacking a lot more costly than it would otherwise be.
    - rimantas 11y ago
      Well, latest SSH vulnerabilities came from the official repos as well. Sure, those were bugs not evil modifications, but still.
      - lmm 11y ago
        Yeah, I know. That was awful and should have resulted in policy changes; it hasn't, and I don't use Debian any more. But it makes a good example of the right approach to package infrastructure.
        solidpy 11y ago
        Is there a distro with a stronger policy than Debian? what are you using now?
        lmm 11y ago
        I wouldn't think stronger than Debian, but there are plenty of distros with equivalent policies. At the moment I'm running FreeBSD (not especially for security reasons).
  - solidpy 11y ago
    Checkout docker-notary [0] a tool for checking signatures that you can pipe in between the download and execution of the script. [0] https://github.com/docker/notary https://github.com/docker/notary

For example, in this case any cert you blindly create with the example will have you located in Paris, France, which may not be accurate. So, never blindly pipe the web into your bash, kids.

digitalsushi 11y ago
You know, I've struggled with this concept. I agree that we shouldn't pipe a URL into a bash script without knowing what it is. But an unsigned software repository that calls post install scripts seems just as absolutely easy to modify, and we see those regularly. My software is most easily installed with a piped bash script. In the script contents, I try to explain what's going on. I also at the top indicate that you shouldn't just trust what I am telling you. And then in the documentation, where you are told how to run the script, I tell you to be cautious there as well. (The script just installs the repository, and from there it's all signed and delivered over https). I could never get over how easy it would be to whitewash a bash script with an rpm just to get some psychological credibility. If it's not signed and/or delivered over https, it's completely hackable. That first step of trust, how?
- lmm 11y ago
  People who are serious about their security run something like Debian and only install from the official repositories, where all packages are signed with GPG and all package maintainers must be part of the web of trust (i.e. have had their identity vouched for by at least one other Debian maintainer). Of course you have to make sure the original install is trustworthy; all you can really do for that is compare the .iso checksum on several different machines. If all those machines are compromised (or there's a hardware-level compromise of your machine) then you're doomed, but that at least makes attacking a lot more costly than it would otherwise be.
  - rimantas 11y ago
    Well, latest SSH vulnerabilities came from the official repos as well. Sure, those were bugs not evil modifications, but still.
    - lmm 11y ago
      Yeah, I know. That was awful and should have resulted in policy changes; it hasn't, and I don't use Debian any more. But it makes a good example of the right approach to package infrastructure.
      - solidpy 11y ago
        Is there a distro with a stronger policy than Debian? what are you using now?
        lmm 11y ago
        I wouldn't think stronger than Debian, but there are plenty of distros with equivalent policies. At the moment I'm running FreeBSD (not especially for security reasons).
- solidpy 11y ago
  Checkout docker-notary [0] a tool for checking signatures that you can pipe in between the download and execution of the script. [0] https://github.com/docker/notary https://github.com/docker/notary