To put my cards on the table: RubyGems.org seems plenty trustworthy to me. They seem to be shitty at communication, but locking down production access to systems in light of the state of supply chain attacks in 2025 is the kind of thing that reduces the risk of rogue repo-level activity.
But to your comment: I'm not arguing the same, I'm arguing that the results are the same. If I'm consuming packages from a repo, and I care about the security of the thing I'm running, I need to think about how I know I'm getting legitimate code that does what I expect it to do. One of the risks to that is malicious developers at the package level (either outright malicious or stolen publish credentials). Another is malicious substitution by the package repo. The detection strategies and next steps are different but as a consumer of code, bad code is a risk regardless of who injects it.
Nonsense. The solution to a malicious package is to not use that single package. The solution to a malicious package repository is to abandon that package repository entirely.
Also, you don't secure a package repository through hostile takeovers, and you certainly don't build trust with such an obvious lie. Claiming that the current rubygems.org is in any way trustworthy is utterly absurd.
But to your comment: I'm not arguing the same, I'm arguing that the results are the same. If I'm consuming packages from a repo, and I care about the security of the thing I'm running, I need to think about how I know I'm getting legitimate code that does what I expect it to do. One of the risks to that is malicious developers at the package level (either outright malicious or stolen publish credentials). Another is malicious substitution by the package repo. The detection strategies and next steps are different but as a consumer of code, bad code is a risk regardless of who injects it.