[lbn]

curl|bash is no less secure than any script you download and run as a regular user. When you add a third party apt repository and install a deb package do you always verify that the postinst script doesn't do anything malicious?

The only mistake I see in this case is doing this over plain HTTP. Let's Encrypt is free and there is no excuse for not enforcing HTTPS for this.

[oholiab]

It's actually possible to detect the |bash part server side and send different content than if you were simply curling, wgeting or viewing in a browser.

Not only does this mean that you could end up with a compromised system, but it also means that there's no artefact of what caused it left on disk.

I agree with your point that running third party software is always a risk, the problem here being that you can think you've done your due diligence by reading the curl output first and then doing curl|bash, but in actuality this is not necessarily the case which is what makes curl|bash such an insidious bad habit.

https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

[ricardobeat]

Does anyone read install scripts/formulas when installing something from system package managers?

[bluecmd]

No, but I trust my OS distribution. I don't trust random third-party developer. I wouldn't add their APT repository willy nilly either.

[semi-extrinsic]

On Arch, installing from AUR people are told to (and generally will) inspect the install script(s) when installing something. It's part of the workflow for all AUR helpers.

[cyphar]

> When you add a third party apt repository and install a deb package do you always verify that the postinst script doesn't do anything malicious?

Package managers have decades of work put into them. Not just the installation and verification aspects, but all of the maintainence bureaucracy required so that there is accountability and verification. As much as developers might like to think that we know more about our users than anyone else, we don't. And there's essentially no verification or reason to believe that an upstream curl|sh will work on a given distribution. People who package software are usually part of the distro community they're packaging for, and are much better at knowing how software should be packaged for that community.

[drdaeman]

Your parent comment was referring to the third-party repositories, and they're not subject to strict packaging policies and may contain just anything. So, the comparison is mostly correct - it's like downloading a random .deb file off the web (only worse, because a trusted malicious repo can override any system package with an "upgrade" - AFAIK there's no package-level signatures in dpkg).

However, not sure about the the implied conclusions (or my perceptions of them). I believe, the correct answer is that adding untrusted repositories is also dangerous and should be done with caution.

And, yes, when I add external repos, I consider a quick background check on who runs it, how popular (=trusted by others) it is, and depending on my conclusions about the trustworthiness, do audit the package contents or perform a test run in a VM. Others' mileage may vary.

[yellowapple]

Security issues aside, there's also the concern of what happens if the piped-into `bash` receives an incomplete script (usually because `curl` was interrupted, often because of poor network connectivity). `bash` will attempt to execute whatever it already got from `curl`, which can cause all sorts of problems.

[ChoHag]

Server: ... rm -fr /$variable

Network: ... rm -fr / <HUP>

Bye bye everything!

[heinrich5991]

That doesn't happen if you put all the main code into a function. Which they do.