[ownagefool]

It's more complicated than that.

curl http | bash - you're basically throwing caution to the wind as everyone between you and the server can rewrite the request, meaning a fairly large number of people who serve you something malicious.

curl https | bash - you're putting your trust in the server, and the PKI / CA infrastructure. A small amount of people can hurt you. If we park the PKI argument, only the owner of the server can attack you. The problem here is, the server owner can specifically detect your behaviour, and take advantage of your trust.

language specific - _generally_ you're pulling a hash from a repository that's public and many people can and do audit. You can't be spot served a slightly different, malicious version of a file, without it first being published for others to see. This means the vendor risks their reputation with this kind of attack, and you're likely to find out about it at some point down the line.

Obviously reality is slightly more complicated, but if your language package manager is relatively modern, pulls and checks via hash, and offers up a .lock file functionality, then it's quite a bit different from a curl http(s) | bash.

[rakoo]

For starters I think we can agree that no-TLS is just out of the question in any case.

You are right that there is a difference, but to me the real threat model is different: in your comparison you assume that the original author is legit but the vendor can be malicious. I believe it's more accurate to assume the original author is malicious. In that case:

curl https | bash - you are compromised

language specific - the malicious author's content isn't checked before it is being pushed. They have a window of opportunity before being discovered by the community and be banned, but the hashes don't protect: the verification must be done manually

third-party repos - I'll only take the example of AUR because it's the one I know best: if the malicious author is also the packager, the situation is the same as the previous one. But, as is often the case, if the malicious author is not the packager, the latter has to be convinced to serve bad content and acts as a simple gateway

[ownagefool]

Agreed yeah.

There's a whole bunch of complexity that goes into whether or not your should trust an entity.

In general though, my opinion, if you use reasonably popular and thus regularly audited packages, you have protective monitoring, and a defense-in-depth framework, there is obviously still a risk of you being first to pick up a bad commit, but you can mitigate those relatively well.

Front end has different considerations. I believe you can defend against the magecarts of the world with CSP but it's not my own forte.

The big thing is, of course, if you're not willing to do your part scanning, reviewing and auditing, nobody else will. Tragedy of the commons and all that.