|
|
|
|
|
|
by oskapt
2062 days ago
|
|
|
Has anyone ever in the history of complaining about this type of script run one and had it nuke their computer? What are the odds that the domains and companies and projects that use this have built their online presence just to pwn your computer for the lulz or that they have been compromised by a malicious actor without being detected at the same time you run the installer, and no one anywhere said anything? How about if instead we exercise critical thinking and make our own assessment of the risk and act accordingly? Why would you choose not to pipe a shell script from a site you don’t trust but execute their installer instead? If you don’t want to pipe it, download it and read it first. |
|
|
But I don't pretend there's no security risk in doing so. Like you advised, I exercise critical thinking, and then I take a risk.
On someone else's production machine, or a container with sensitive data, that risk is too high. On a fun machine in isolation it's fine.
The GPP asks what's the security difference between inspecting and not inspecting the downloaded command.
> or that they have been compromised by a malicious actor without being detected at the same time you run the installer
Installers are compromised quite often by malicious actors. Running an installer is just as dubious as running "curl | sh".
However, replacing an installer with one that looks the same but is actually malicious, is a lot more work than replacing a blind script with one that looks the same but is actually malicious.
And the risk of a malicious blind script going unnoticed is higher than a compromised installer when the SHA256 is shown to be checked alongside the latter's link, simply because the attacker would need to change two places instead of one. Yes I do check hashes of installers when that's possible and there isn't a package manager already doing so. It's a good idea anyway in case of a corrupted download file, which I do see from time to time.