4 ms·

Hear, hear! It is completely irresponsible to encourage piping random Internet sources to sudo or to (ba)sh, and I'm quite tired of hearing the ridiculous just

Hear, hear! It is completely irresponsible to encourage piping random Internet sources to sudo or to (ba)sh, and I'm quite tired of hearing the ridiculous justification that "everyone does it".

jamespo 3y ago
do you read the script sections of all the packages you install?
- gabrielgio 3y ago
  No, it is unfeasible (at least for me) to validate every single package. So at some point I have to trust someone/ some party and I chose to trust more the maintainers of my distro than a person asking me to run sudo from curl.
  - Joker_vD 3y ago
    And some people trust the software authors more than some random repo maintainers who don't have enough time to even make sure the packages they update are actually still compatible with each other.
  - codedokode 3y ago
    You do not need to trust anyone if the program is run inside a sandbox. This sandbox is supported in hardware since 80386, but Linux doesn't make proper use of it.
- johnklos 3y ago
  Yes, or I get my packages through a trusted package system, such as pkgsrc.
- oneshtein 3y ago
  In Linux, to install virus or malware, you need to download, compile, and install virus manually, OR user can install it using `curl ... | bash`, which is much simpler method. Even newbies can install new malware using `curl ... | bash`.
notnmeyer 3y ago
sudo, yes. piping to a shell is fine imo provided the install script is easy enough to read if you are so inclined. i have seen lots of generated install scripts that are mind boggling. the reality is that you run code you haven’t personally read and vetted everyday. so the idea that you need some stranger to bless a package for you to be trustworthy doesn’t make a whole lot of sense.
beeburrt 3y ago
So these are all a bad way of installing? https://bun.sh/ https://bun.sh/ https://www.rust-lang.org/tools/install https://www.rust-lang.org/tools/install https://deno.land/manual@v1.36.1/getting_started/installation https://deno.land/manual@v1.36.1/getting_started/installatio... I'm not disagreeing with you, as a beginner, I'm just trying to learn.
- quectophoton 3y ago
  "It depends". The answer for this has multiple parts. Though my preference is using my OS package manager (so I'm biased towards that), I'll try to explain my reasoning as best as possible. And I'm using "OS" in a liberal sense, to also mean "different linux distros" and "BSDs". --- One, you have to also think about what happens after installing. You have to consider upgrades, uninstalls, and also errors happening during those processes. With these scripts, if something goes wrong you're mostly on your own (though yes, you can go to the specific support channels for the specific software to fix the specific problem for your specific situation). Your Deno link at least is versioned so it would be less bad to debug if something goes wrong, but that's only relatively speaking. A package manager deals mostly with static archives, and keeps track of any file controlled by it. It is trivial to know whether a particular file belongs to a specific package or not. Upgrades can be centrally managed. Since it knows about what programs it has installed, it can print you a list of names and versions of everything so you can compare it against a list of CVEs or something. Custom installation scripts are custom, and each has their own way to do these things. --- Second, those instructions tell you to run a random script without even verifying its integrity first. No versioning for that script, no auditability trail, no signature to guarantee that the script is indeed the same as the script's author uploaded some moment in the past and has not been tampered with since. A package manager deals (usually) with static archives whose signatures are verified before trying to do anything with them. An install operation is a simple, boring, "extract archive". Maybe with a small post-install script (that was part of the signed archive). And the public keys used by the package managers are (usually) already in your local machine, so for most operations you are using an already-known public key to validate signatures. (Note: Presence of a signature does not imply the software is trusted. It only means that the person that signed the thing had access to the private key.) --- Third, though this sometimes causes problems (but I have never experienced them, or at least nothing comes to mind), the maintainer of your OS package repository usually knows your OS better than the upstream developer, and can apply patches to the packaged software that can be bug fixes, or even disabling/removing telemetry that the upstream software has enabled by default. And with a package manager you know there's at least one other person (the maintainer of the package) that has used this program in this specific OS. There may be the case that some versions are just packaged without actual testing (just "git pull & run packaging scripts" or the equivalent), but in those cases there's the escape hatch of installing a previous, working version of the package. --- With that said. If you were to ask me if there would be a situation where I would use those scripts, then _maybe_ (big maybe) it would be (1) inside a container where I don't care about any garbage left behind because I can nuke the whole thing at once; or (2) in an isolated environment where I don't even care if the script needs root privileges (this second case implies I would not do this in Docker).
pacifika 3y ago
It would be interesting if there was a dsl scripting language with the only purpose of installing software

Hear, hear! It is completely irresponsible to encourage piping random Internet sources to sudo or to (ba)sh, and I'm quite tired of hearing the ridiculous justification that "everyone does it".

jamespo 3y ago

do you read the script sections of all the packages you install?

gabrielgio 3y ago
No, it is unfeasible (at least for me) to validate every single package. So at some point I have to trust someone/ some party and I chose to trust more the maintainers of my distro than a person asking me to run sudo from curl.
- Joker_vD 3y ago
  And some people trust the software authors more than some random repo maintainers who don't have enough time to even make sure the packages they update are actually still compatible with each other.
- codedokode 3y ago
  You do not need to trust anyone if the program is run inside a sandbox. This sandbox is supported in hardware since 80386, but Linux doesn't make proper use of it.
johnklos 3y ago
Yes, or I get my packages through a trusted package system, such as pkgsrc.
oneshtein 3y ago
In Linux, to install virus or malware, you need to download, compile, and install virus manually, OR user can install it using `curl ... | bash`, which is much simpler method. Even newbies can install new malware using `curl ... | bash`.

notnmeyer 3y ago

sudo, yes. piping to a shell is fine imo provided the install script is easy enough to read if you are so inclined. i have seen lots of generated install scripts that are mind boggling. the reality is that you run code you haven’t personally read and vetted everyday. so the idea that you need some stranger to bless a package for you to be trustworthy doesn’t make a whole lot of sense.

beeburrt 3y ago

So these are all a bad way of installing? https://bun.sh/ https://bun.sh/ https://www.rust-lang.org/tools/install https://www.rust-lang.org/tools/install https://deno.land/manual@v1.36.1/getting_started/installation https://deno.land/manual@v1.36.1/getting_started/installatio... I'm not disagreeing with you, as a beginner, I'm just trying to learn.

quectophoton 3y ago
"It depends". The answer for this has multiple parts. Though my preference is using my OS package manager (so I'm biased towards that), I'll try to explain my reasoning as best as possible. And I'm using "OS" in a liberal sense, to also mean "different linux distros" and "BSDs". --- One, you have to also think about what happens after installing. You have to consider upgrades, uninstalls, and also errors happening during those processes. With these scripts, if something goes wrong you're mostly on your own (though yes, you can go to the specific support channels for the specific software to fix the specific problem for your specific situation). Your Deno link at least is versioned so it would be less bad to debug if something goes wrong, but that's only relatively speaking. A package manager deals mostly with static archives, and keeps track of any file controlled by it. It is trivial to know whether a particular file belongs to a specific package or not. Upgrades can be centrally managed. Since it knows about what programs it has installed, it can print you a list of names and versions of everything so you can compare it against a list of CVEs or something. Custom installation scripts are custom, and each has their own way to do these things. --- Second, those instructions tell you to run a random script without even verifying its integrity first. No versioning for that script, no auditability trail, no signature to guarantee that the script is indeed the same as the script's author uploaded some moment in the past and has not been tampered with since. A package manager deals (usually) with static archives whose signatures are verified before trying to do anything with them. An install operation is a simple, boring, "extract archive". Maybe with a small post-install script (that was part of the signed archive). And the public keys used by the package managers are (usually) already in your local machine, so for most operations you are using an already-known public key to validate signatures. (Note: Presence of a signature does not imply the software is trusted. It only means that the person that signed the thing had access to the private key.) --- Third, though this sometimes causes problems (but I have never experienced them, or at least nothing comes to mind), the maintainer of your OS package repository usually knows your OS better than the upstream developer, and can apply patches to the packaged software that can be bug fixes, or even disabling/removing telemetry that the upstream software has enabled by default. And with a package manager you know there's at least one other person (the maintainer of the package) that has used this program in this specific OS. There may be the case that some versions are just packaged without actual testing (just "git pull & run packaging scripts" or the equivalent), but in those cases there's the escape hatch of installing a previous, working version of the package. --- With that said. If you were to ask me if there would be a situation where I would use those scripts, then _maybe_ (big maybe) it would be (1) inside a container where I don't care about any garbage left behind because I can nuke the whole thing at once; or (2) in an isolated environment where I don't even care if the script needs root privileges (this second case implies I would not do this in Docker).

pacifika 3y ago

It would be interesting if there was a dsl scripting language with the only purpose of installing software