It's the age old root of trust problem. In practice the good enough is that if it passes SSL/TLS authentication on the official domain then we wouldn't be able to stop an injection attack either way. Validating against the source is no good if it is the source that is compromised.
That's also kind of the issue with a lot of these shell injection attacks. Sure someone could insert environment variables or other shenanigans to take over your machine, but if they have that much control over your shell there are countless other ways they could also do it. Guarding against this one particular case doesn't buy you much.
It's called apt. Or dnf. Or most any package manager. Having a gigantic general list runs into the problem of how do you update it and how do you verify the updates?
You use GPG and trust the people publishing things, who sign the artifact that you actually download. Which is internally how every package manager I've seen works internally, anyways.
We haven’t been able to trust public pgp keyservers for a decade or more (possibly never, really).
So now we’re back at having to trust where-ever we get the proof from, whether that’s the file hash, or the public key.
(Which, as you say, is what package managers provide, and if you don’t trust your system’s apt/yum/pacman/whatever, then you have a bigger problem that trusting any random install shell script)
