Malicious people do malicious things? I worry that we conflate trust with validity. Some package systems do it better than others, but in principle you trust that for example, a maintainer of a package repository is not serving you bad checksums and malicious content. After all these systems get their checksums/keys on-first-use, so you still need to make the trust judgement. And they could still change the responses based on your ip, user agent, or other metadata they have access to when you interact with the system.
To boil it down to my gripe, the comments about checksums/gpg signing being the reason to never 'curl | sh' make no sense until you can clear the trust argument first, which no one does. And once you do clear the trust argument, and conclude the source is trustworthy, we can have a more technical debate on the distribution mechanism itself and what makes sense from that perspective.
edit: forgot to add, 'curl | sh' is also a trust on-first-use scenario just like with package ecosystems.
A compromise from a malicious curl|bash script is basically impossible to detect. All other avenues at least give you the potential ability to figure out how you were compromised after the fact. With curl|bash there is no trail and you can never find out which commands were actually excecuted, because it's possible to detect the |bash on the server that's providing the script.
Since we've passed the trust gate up to this point for discussion purposes, I still wonder if there is a better model for young projects. Its not just we have multiple package formats, its the per distro/version matrix that tends to bite small developers and projects on time commitment. I would like to see something better than 'curl | sh' that is practical and portable across the unix-y ecosystem. Perhaps a third-party checksum db that caches valid script hashes ala golang sumdb or similar. Seems ripe for improvement.
Sure, but what you're missing is that this argument would also strike down package managers. For example, you could similarly fingerprint the difference in behaviors for apt-get vs normal http utilities and only serve malicious packages to people grabbing via apt (likely someone trying to run the code) vs downloading in a browser or via curl/wget (most likely an auditor). This is trivial to do and of course individual packages as well as entire package delivery mechanisms have been compromised.
The value add for package systems is signatures.
Feel free to create a proof of concept if that's actually possible, then you'll be able to discuss it.
You'll likely also get incredible job offers as that would be a Goldmine for blackhats and various state actors
But I'd agree that the hurdle to get your package into system repositories likely ain't with it. People are free to compile it themselves, download it manually or whatever floats their boats if they don't want to use the quick and easy install script... Which they can audit by saving it to the filesystem before executing the file.