5 ms·

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://ni

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
  [deleted]
nickysielicki 10y ago
What do you find inadequate about PGP key-servers?
- __david__ 10y ago
  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?
  - falcolas 10y ago
    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.
    - oconnore 10y ago
      > 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?
      - falcolas 10y ago
        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.
- oconnore 10y ago
  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.
regularfry 10y ago
That's not the only thing you have to trust. http://ariya.ofilabs.com/2016/05/nix-as-os-x-package-manager.html 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 http://thejh.net/misc/website-terminal-copy-paste

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
[deleted]

nickysielicki 10y ago

What do you find inadequate about PGP key-servers?

__david__ 10y ago
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?
- falcolas 10y ago
  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.
  - oconnore 10y ago
    > 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?
    - falcolas 10y ago
      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.
oconnore 10y ago
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.

regularfry 10y ago

That's not the only thing you have to trust. http://ariya.ofilabs.com/2016/05/nix-as-os-x-package-manager.html 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 http://thejh.net/misc/website-terminal-copy-paste