Using

curl -s https://url | sudo bash

is literal insanity. Root given. We know how accounts can be compromised, so obviously there is potential for that url to be replaced by a hacker with something malicious. We've even seen hackers compromise pages, and return the standard page, while targetting only a few people (geolocation, for example) with malicious data.

Yet there is also the possibility for malformed text to be returned. Bash will happily execute each and every line of:

  E#@%SDVsdcvxdsf4a6t4g
  erfgrr;rm * regdfgereridbd
  4524wfasrfv4

Hard to imagine such output? Yes. Impossible? Absolutely not. There are literally thousands upon thousands of commands bash can access in a typical install of Linux. Many of them are destructive. Why even risk it?

And beyond malformed, there could be a simple publishing error. There could be lines of code in the error message. Unknown text. Each and every line of text returned, is executed. I am just gobsmacked that this exists anywhere, ever, for any reason at all. I wouldn't execute such a command from my own personal web server, in my own internal lan, let alone remote.

When I see such inanity on a project page, it's a big read flag to me. Convenience over the most basic of security, or even simple validation that something didn't go wrong in a curl request. The evoked lack of trust that arises is as bile in my throat, what other shortcuts are taken by the project authors, which seem to barely understand the simplest of risk assessment?

Please, don't ever execute this. If you have to throw all sense and caution to the wind, and use a project which suggests this install method, well... at least curl > file and take 1 second to see the result.