5 ms·

> curl https://nixos.org/nix/install https://nixos.org/nix/install | sh Stop doing this. Look, even if you are rolling your eyes and thinking, "it's https and

> curl https://nixos.org/nix/install https://nixos.org/nix/install | sh Stop doing this. Look, even if you are rolling your eyes and thinking, "it's https and I'm not Ed Snowden, I think I can afford the risk for the benefit of an easy install process", what happens if curl is interrupted? Are you excited at the prospect of a half-ran install script that you didn't even look at?

hso1 10y ago
Yes. I'm unconfortable doing this as well. Not only with Nix, I really think you shouldn't do it, ever. On Ubuntu/Debian, at least, I'm installing the .deb package.
bydo 10y ago
The install script (for Nix, at least) is written such that it will not execute if partially downloaded, so that is less of an issue. Though I do agree wholeheartedly that piping scripts to shell, sight unseen, is a remarkably awful idea.
vertex-four 10y ago
The script doesn't run if it downloads. Go read it yourself. What attack vector would you actually be protecting against if you downloaded a .tar.gz full of binaries and extracted it to /, then started installing things with it?
- bydo 10y ago
  On that note, is there some valid reason Nix absolutely needs access to / to create /nix? Why can't it live somewhere else? I believe some parts can go anywhere, but /nix is hard coded for the rest, which I'm not entirely comfortable with.
  - hso1 10y ago
    I don't know for sure, but I think it's installed under /nix thinking of multi-user Nix installs. With Nix any system user can install its own set of packages and on NixOS there are build users that install packages on behalf of normal users.
  - vertex-four 10y ago
    All Nix packages are built with full-path references to other packages in Nix - if you move it elsewhere, the result is that you can't use the binary cache built by Hydra, and you have to build everything from source.
  - pmahoney 10y ago
    The pre-built binary packages available from the Nix project are all compiled for /nix; this choice is baked in to the binaries, which refer to shared libs via absolute paths for example. I understand this path is configurable, but you'll be compiling everything yourself, unable to use Nix's binary cache. You also risk running into unique problems since everyone else is using /nix
    - mitchty 10y ago
      Yep, additionally, /nix is really no different than /usr/local here. Just in a different spot. I'd recommend everyone try nixos out as well to see why everything (mostly) in /nix is a good idea. nixos is easily the most un unix unix i've seen, and honestly i can't wait to get rid of apt/rpm/yum/zypper. Not dealing with /some/file/blah being version X or Y in general is so freeing.
    - hk__2 10y ago
      > I understand this path is configurable, but you'll be compiling everything yourself, unable to use Nix's binary cache Not necessarily. Homebrew compiles stuff for a special prefix then substitutes your own prefix when you install the binary. It doesn’t work with everything (that’s why some compiled packages are available for /usr/local only) but it’s a start.
      - cstrahan 10y ago
        Nix uses rpaths on Linux (install names on OSX) to fix the precise location of dynamically linked dependencies, and it also patches the paths to executables (e.g. In string laterals or shebangs) needed at run time. To change the location of a binary, one would have to patch the dependents so that /nix/store is replaced with the new prefix, which is generally not possible to do, unless the new prefix has the same length as the old prefix - in which case you can just sed every file. Homebrew just assumes that the needed executables will be available on $PATH and that the dynamic linker will find libs in /usr/lib or /usr/local/lib. So yes, you really would need to recompile everything if change the prefix from /nix/store to something else. Edits: fixed spelling and structure from originally typing via phone.
- nickysielicki 10y ago
  Good point, I didn't look at the script. My point about half-downloads is bogus. Kind of a funny situation. If you look at the script first, you'll notice that it would have been okay for the download to be interrupted and so, assuming everything else is kosher with you, the '| sh' would have been "safe". And if you don't look at the script first, you'd never know that what you just did was "safe." Schroedinger's-pipe-to-sh.
  - grhmc 10y ago
    I think this is just "good design," you expect tools to be designed to handle failure in a reasonable way.
    - falcolas 10y ago
      You might expect it, but if you're blindly running `curl > sh` (as recommended), you can't be certain.
wired_devil 10y ago
Take a look at the install script. It's not so complicated, pretty much only download a tar.gz. So why using curl?
- hso1 10y ago
  Did you know that a malicious server can detect if you are piping to a shell and serve a completely different thing? D:
  - JonnieCache 10y ago
    How so? By looking for a curl UA?
    - hso1 10y ago
      No. The shell is slower processing the download. You can detect this on the server. See https://news.ycombinator.com/item?id=11532599 https://news.ycombinator.com/item?id=11532599
    - deleted 10y ago
      [deleted]
- hk__2 10y ago
  > It's not so complicated, pretty much only download a tar.gz. So why using curl? Because it goes further than just downloading a .tar.gz. It checks your OS and its dependencies; download the right tarball; check it has an install script; run the install script.
oconnore 10y ago
No [1]. If you are installing software from scratch, you must trust the https server that serves it to you. They could publish sha256 check sums to https://nixos.org/hashes https://nixos.org/hashes, but you would have to trust the https server. They could publish their gpg key to https://nixos.org/gpg https://nixos.org/gpg, but you would have to trust the https server. Things would be better if we had a reasonable certificate system for verifying open source software, but we don't. There is no gpg web of trust. There is no hierarchical CA system for code signing that open source authors can easily plug into, and expect their users to verify. If you care this much, stop astroturfing and go build a system that does better. It will be very hard work, and you will have to distribute the first version of your solution with an https server that your users will have to trust. [1]: Ok, so maybe the instructions could be "curl <url> -o install.sh && sh install.sh".
- falcolas 10y ago
  > If you are installing software from scratch, you must trust the https server that serves it to you This is incorrect - you are forced by `curl | sh` to trust all of the 1000+ CAs in your OS' keystore. And if you can't trust all of them (since some have given out Google certs before, you can't), how can you trust what you're getting over HTTPS? With hashes, they are not typically served from the same domain. That's the minimum level of protection for the user. Signing with a key is another level of protection; it lets the user (not the OS) decide the level of trust, and even verify the key with the author of the package via a completely separate channel. Now the question really becomes, why doesn't the provider use the existing (secure) channels of software distribution? RPMs, DEBs, installer packages for Macs, MSAs for Windows?
  - danpalmer 10y ago
    > you are forced by `curl | sh` to trust all of the 1000+ CAs in your OS' keystore. And if you can't trust all of them If you don't trust them, they should not be in your certificate store. That's not a problem with using `curl | sh`, it's a problem with the certificate store and what the user is trusting.
  - deleted 10y ago
nefariousoctopi 10y ago
There is even timing server side attack exploiting "curl |bash" recently posted on HN [1]. [1]: https://news.ycombinator.com/item?id=11532599 https://news.ycombinator.com/item?id=11532599
- chrismonsanto 10y ago
  This is an irrelevant "attack." If you don't trust the site to serve you a safe installer, then you shouldn't trust the site to serve you a safe program either. Do you regularly verify the entire source code of programs you install?
eridius 10y ago
> what happens if curl is interrupted? Absolutely nothing. The script is written intelligently, so an interrupted download just results in a syntax error. Specifically, the entire file is wrapped in {}, and if the terminating } is missing, sh will throw an "unexpected end of file" error instead of executing anything.

hso1 10y ago

Yes. I'm unconfortable doing this as well. Not only with Nix, I really think you shouldn't do it, ever. On Ubuntu/Debian, at least, I'm installing the .deb package.

bydo 10y ago

The install script (for Nix, at least) is written such that it will not execute if partially downloaded, so that is less of an issue. Though I do agree wholeheartedly that piping scripts to shell, sight unseen, is a remarkably awful idea.

vertex-four 10y ago

The script doesn't run if it downloads. Go read it yourself. What attack vector would you actually be protecting against if you downloaded a .tar.gz full of binaries and extracted it to /, then started installing things with it?

bydo 10y ago
On that note, is there some valid reason Nix absolutely needs access to / to create /nix? Why can't it live somewhere else? I believe some parts can go anywhere, but /nix is hard coded for the rest, which I'm not entirely comfortable with.
- hso1 10y ago
  I don't know for sure, but I think it's installed under /nix thinking of multi-user Nix installs. With Nix any system user can install its own set of packages and on NixOS there are build users that install packages on behalf of normal users.
- vertex-four 10y ago
  All Nix packages are built with full-path references to other packages in Nix - if you move it elsewhere, the result is that you can't use the binary cache built by Hydra, and you have to build everything from source.
- pmahoney 10y ago
  The pre-built binary packages available from the Nix project are all compiled for /nix; this choice is baked in to the binaries, which refer to shared libs via absolute paths for example. I understand this path is configurable, but you'll be compiling everything yourself, unable to use Nix's binary cache. You also risk running into unique problems since everyone else is using /nix
  - mitchty 10y ago
    Yep, additionally, /nix is really no different than /usr/local here. Just in a different spot. I'd recommend everyone try nixos out as well to see why everything (mostly) in /nix is a good idea. nixos is easily the most un unix unix i've seen, and honestly i can't wait to get rid of apt/rpm/yum/zypper. Not dealing with /some/file/blah being version X or Y in general is so freeing.
  - hk__2 10y ago
    > I understand this path is configurable, but you'll be compiling everything yourself, unable to use Nix's binary cache Not necessarily. Homebrew compiles stuff for a special prefix then substitutes your own prefix when you install the binary. It doesn’t work with everything (that’s why some compiled packages are available for /usr/local only) but it’s a start.
    - cstrahan 10y ago
      Nix uses rpaths on Linux (install names on OSX) to fix the precise location of dynamically linked dependencies, and it also patches the paths to executables (e.g. In string laterals or shebangs) needed at run time. To change the location of a binary, one would have to patch the dependents so that /nix/store is replaced with the new prefix, which is generally not possible to do, unless the new prefix has the same length as the old prefix - in which case you can just sed every file. Homebrew just assumes that the needed executables will be available on $PATH and that the dynamic linker will find libs in /usr/lib or /usr/local/lib. So yes, you really would need to recompile everything if change the prefix from /nix/store to something else. Edits: fixed spelling and structure from originally typing via phone.
nickysielicki 10y ago
Good point, I didn't look at the script. My point about half-downloads is bogus. Kind of a funny situation. If you look at the script first, you'll notice that it would have been okay for the download to be interrupted and so, assuming everything else is kosher with you, the '| sh' would have been "safe". And if you don't look at the script first, you'd never know that what you just did was "safe." Schroedinger's-pipe-to-sh.
- grhmc 10y ago
  I think this is just "good design," you expect tools to be designed to handle failure in a reasonable way.
  - falcolas 10y ago
    You might expect it, but if you're blindly running `curl > sh` (as recommended), you can't be certain.

wired_devil 10y ago

Take a look at the install script. It's not so complicated, pretty much only download a tar.gz. So why using curl?

hso1 10y ago
Did you know that a malicious server can detect if you are piping to a shell and serve a completely different thing? D:
- JonnieCache 10y ago
  How so? By looking for a curl UA?
  - hso1 10y ago
    No. The shell is slower processing the download. You can detect this on the server. See https://news.ycombinator.com/item?id=11532599 https://news.ycombinator.com/item?id=11532599
  - deleted 10y ago
    [deleted]
hk__2 10y ago
> It's not so complicated, pretty much only download a tar.gz. So why using curl? Because it goes further than just downloading a .tar.gz. It checks your OS and its dependencies; download the right tarball; check it has an install script; run the install script.

oconnore 10y ago

No [1]. If you are installing software from scratch, you must trust the https server that serves it to you. They could publish sha256 check sums to https://nixos.org/hashes https://nixos.org/hashes, but you would have to trust the https server. They could publish their gpg key to https://nixos.org/gpg https://nixos.org/gpg, but you would have to trust the https server. Things would be better if we had a reasonable certificate system for verifying open source software, but we don't. There is no gpg web of trust. There is no hierarchical CA system for code signing that open source authors can easily plug into, and expect their users to verify. If you care this much, stop astroturfing and go build a system that does better. It will be very hard work, and you will have to distribute the first version of your solution with an https server that your users will have to trust. [1]: Ok, so maybe the instructions could be "curl <url> -o install.sh && sh install.sh".

falcolas 10y ago
> If you are installing software from scratch, you must trust the https server that serves it to you This is incorrect - you are forced by `curl | sh` to trust all of the 1000+ CAs in your OS' keystore. And if you can't trust all of them (since some have given out Google certs before, you can't), how can you trust what you're getting over HTTPS? With hashes, they are not typically served from the same domain. That's the minimum level of protection for the user. Signing with a key is another level of protection; it lets the user (not the OS) decide the level of trust, and even verify the key with the author of the package via a completely separate channel. Now the question really becomes, why doesn't the provider use the existing (secure) channels of software distribution? RPMs, DEBs, installer packages for Macs, MSAs for Windows?
- danpalmer 10y ago
  > you are forced by `curl | sh` to trust all of the 1000+ CAs in your OS' keystore. And if you can't trust all of them If you don't trust them, they should not be in your certificate store. That's not a problem with using `curl | sh`, it's a problem with the certificate store and what the user is trusting.
- deleted 10y ago

nefariousoctopi 10y ago

There is even timing server side attack exploiting "curl |bash" recently posted on HN [1]. [1]: https://news.ycombinator.com/item?id=11532599 https://news.ycombinator.com/item?id=11532599

chrismonsanto 10y ago
This is an irrelevant "attack." If you don't trust the site to serve you a safe installer, then you shouldn't trust the site to serve you a safe program either. Do you regularly verify the entire source code of programs you install?

eridius 10y ago

> what happens if curl is interrupted? Absolutely nothing. The script is written intelligently, so an interrupted download just results in a syntax error. Specifically, the entire file is wrapped in {}, and if the terminating } is missing, sh will throw an "unexpected end of file" error instead of executing anything.