| > I always get bothered when people bring up the `curl [...] | bash` “argument” (which is usually less of an argument and more of a rude dismissal of a good product). Why? Package managers were created for a reason. Virtually every Linux distribution anyone would use to host a service such as Sandstorm will include a package manager. > Not sure, but I’m pretty sure you don’t validate every tarball you download, and even if you do validate them, you certainly wouldn’t look through each line of code making sure there isn’t a backdoor or something. I don't download tarballs. I install packages. Who downloads tarballs to install software in 2016? Anyone actively developing for a project will likely be using git, and I'm not aware of too many projects which make use of toolchains which are so new that they're not available in any rolling release/testing distro. > Any malicious person could break into a tarball download site, and replace the checksums as well (only way to mitigate that is using a signature that is associated with the tarball maintainer), and even if something like PGP is used, the attacker would be able to replace the instructions to obtain the PGP key with their own generated one, or even remove the signature completely. Yes, fine. And that's why all major distributions sign their packages, so you know that it's valid. Again, it's 2016, who seriously installs software from tarballs? > The only thing worse about it is that it’s less noticeable when the script has been replaced. No, what is much worse than that is you are installing software outside of your package manager. Also, companies who deploy via curl | bash, typically pull in their own dependencies outside of the package manager. It's bad form. If your application has specific dependencies, then ship it as an appliance using LXC, Docker, or $TRENDY_CONTAINER_TECH. That way, all updates are atomic and you don't risk eff-ing the OS by pulling in a bunch of stuff outside of the package manager. > In conclusion, please don’t be rude and dismiss an entire product because of a single installation method, which isn’t actually worse than a malicious tarball. In conclusion, package management is a solved problem. Companies which have installers which do not make use of the distribution's package management system are lazy, and anyone who defends curl | bash is an apologist. Seriously, it's not difficult to generate a DEB/RPM/<insert distribution package format> and create your own signed repo. Package management has been a solved problem for at least a decade. It annoys me that companies think it's okay to have curl | bash as an installation method. If they think that will ever be acceptable in an enterprise environment where change management is important, they're delusional. |
Yes, but:
* Most of them ship on a 6-month or even 2-year release cycle whereas Sandstorm updates every week.
* Most of them will not accept a package that wants to self-containerize with its own dependencies, which means Sandstorm would instead have to test against every different distro's dependency packages every week, whereas with self-containerization we only depend on the Linux kernel API -- which is insanely stable.
* If we publish the packages from our own repo, we're back to square one: how does the user get the signing key, if not from HTTPS download?
* Sandstorm actually has a PGP-verified install option: https://docs.sandstorm.io/en/latest/install/#option-3-pgp-ve...
* You should probably be installing Sandstorm in its own VM anyway.
I'm certainly not saying curl|bash is perfect. There are trade-offs. For now this is the trade-off that makes the most sense for us. Later on, maybe something else will make sense.
> If they think that will ever be acceptable in an enterprise environment where change management is important, they're delusional.
We've never had an enterprise customer comment on this (other than requesting the PGP-verified option, which we implemented). The vast majority of complaints come from HN, Twitter, and Reddit. ::shrug::