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, but you would have to trust the https server.

They could publish their gpg key to 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".

> 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?

> 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.

That's not the only thing you have to trust.

http://ariya.ofilabs.com/2016/05/nix-as-os-x-package-manager... is served over HTTP. Saying "Copy and paste this `curl | sh` command" allows this attack: http://thejh.net/misc/website-terminal-copy-paste

What do you find inadequate about PGP key-servers?

So you pull the package down and the signature checks out to some key on a pgp key server. How do you know it's the correct key?

Generally, the key already exists on your system, as it's coming through the official channels. If you decide to add the cert manually, you can inspect the key and see who has signed it, and decide your level of trust.

With HTTPS, you only ever have the choice of trusting the 1000+ CAs in your keyring.

> If you decide to add the cert manually, you can inspect the key and see who has signed it, and decide your level of trust.

No one has signed it, because the mythical web of trust does not exist. What now?

Contact the developer (say, over IRC, Slack, email, GitHub, etc), and ask them to sign a sentence you provide with it. Then you can sign their key.

Where is the web of trust that lets me cryptographically verify that my install.sh file was published by some PhD student in the Netherlands? And unless I trust the https server, how do I know which PhD student in the Netherlands I'm supposed to trust?

If this were software that I had to install multiple times (say there are several updates a year), it might make sense to implement TOFU with a published GPG key -- each successive update would use the same key I imported the first time. However, the nix installer installs a package manager which is self updating, and therefore implements TOFU itself.

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?

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.

I think this is just "good design," you expect tools to be designed to handle failure in a reasonable way.

You might expect it, but if you're blindly running `curl > sh` (as recommended), you can't be certain.

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.

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

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.

> 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.

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.

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.

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.

There is even timing server side attack exploiting "curl |bash" recently posted on HN [1].

[1]: https://news.ycombinator.com/item?id=11532599

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?

> 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.

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.

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.

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

Did you know that a malicious server can detect if you are piping to a shell and serve a completely different thing? D:

How so? By looking for a curl UA?

No. The shell is slower processing the download. You can detect this on the server. See https://news.ycombinator.com/item?id=11532599

> 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.