How often do you see that in cases where someone wasn’t going to run the software anyway? I’m not sure how much of a risk this is adding now that HTTPS has become routine — is it really better to install a tarball, unaudited package on NPM/PyPI/etc.?
Yeah...I don't think I've ever actually done that, but I could see some blog post saying to.
I think an annoying truth that us Linux-users don't like to admit is that another large part of what makes linux "more secure" is that only technical people bother using it. My parents are both smart people, but aren't programmers or anything, and as a result didn't like Linux when I tried to get them to use it; if they did use Ubuntu it's entirely possible that they'd figure out how to get a virus pretty quickly.
I've definitely seen plenty of `curl | bash` installations suggested before (and can honestly say that I've run some, despite knowing the risks), but _sudo_? Is that a thing that people actually do?
At the risk of appearing ignorant.. what exactly is the problem here? Do we trust the nodesource deb repo but we do not trust the bash script which is coming from the nodesource domain?
Deb packages have cryptographic signatures that can be verified to confirm it actually came from nodesource (or whoever)
If you get MITM'd (admittedly difficult with TLS) or the site got compromised (but not the build IX / developer's keyring) it would be possible to replace the script with a malicious one.
Also, you can detect the curl|bash installation method server-side and serve different content [1] on that basis, which is not possible with deb packages.
Finally, providing a curl|bash installation method implies that the developers either do not understand packaging, or don't care about it. This is fine e.g. if developers want to remain platform agnostic or just can't be bothered packaging, but if you develop a curl|bash installer you send the message "I want to distribute my software but don't care enough to do it properly / in a standards compliant way".
Also, and this is more subjective, most curl|bash installers I've seen make assumptions about their environments that do not necessarily hold in less common distributions - which makes you wonder why they don't just develop e.g. a deb if it only works reliably on Ubuntu and maybe Debian.
> Deb packages have cryptographic signatures that can be verified to confirm it actually came from nodesource (or whoever)
And how do you get the GPG key to verify such signatures from third-parties? Usually via https from their website, no?
> Also, you can detect the curl|bash installation method server-side and serve different content
Yes, but you are supposed to trust people you get you packages from not to do it. And so and it should only make a difference if their servers are compromised and they sign packages with a key stored offline.
I think the latter is much less common then one would hope, with release processes in CI and such.
This seems a little different to me than most `curl | bash` scripts, as it's trying to integrate with the system package manager. Not trying to imply the same security implications don't apply, but there's not really a way to integrate with them without requiring root, and it seems like the entire purpose of this is to integrate with the package manager, which gives you things like an easy way to get updates. (From looking further down the instructions, it looks like this is just setting up a PPA on debian-based distros; I'd personally just paste the config into a file myself, but realistically the security concerns are the same, since I think most package managers give the ability to execute custom code as part of the install process, and it'll be running as root when that code is executed)
