Conversation

Replying to and
I do care about the practical implications, and I also realize that a system doesn't need to perfect to mitigate many real attacks. Doing better than trust-on-first-use is hard but it can be built on top of a baseline implementation and isn't required to have lots of value.
1
Nearly every system boils down to some form of trust-on-first-use, like Domain Validation for HTTPS. That just delegates an insecure initial check to many completely trusted authorities and yet in practice it works pretty well, and is a whole lot better than just using HTTP.
1
It doesn't need to be a perfect system to have a lot of value and mitigate many real world attacks. Security nihilism is such a lazy position. I think having TOFU with fingerprints pinned alongside versions is the *least* that people should expect from language package managers.
1
Replying to and
Most Linux distributions fully trust the packagers and a central build / signing server, along with not verifying signatures for sources. I think you're unfamiliar with how it works elsewhere if you think trusting 20 vetted people to sign builds of packages is bad.
2
Having a central build / signing server doesn't mean a developer wasn't also fully trusted with what they told the server to build, without anyone reviewing what they asked it to build. It's usually not the case that a central build server is trusted *instead* of developers.
2