[411111111111111]

I think I wasn't clear enough so I'll try to rephrase it:

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.

[ReganLaitila]

Thanks for the clarification I see now what your getting to. I agree having proper packages makes sense at some point in a project's maturity, as you have more infrastructure, checks, and gates to ensure that what you requested is 'valid', and the system produces enough logs/data to compare to other systems to detect drift/compromise. I tend to see if a project gets popular enough, with enough eyeballs/contributors, official packages tend to become inevitable.

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.