I've had deploys break because gems were removed from RubyGems.org. Using CI as a gate isn't sufficient because a gem can be removed in the window between a com

I've had deploys break because gems were removed from RubyGems.org. Using CI as a gate isn't sufficient because a gem can be removed in the window between a completed CI run and the deploy. Making it harder, generally if you have a gem installed locally you won't notice the problem until you need to install it on a fresh system. It used to be the case that a yanked gem was simply removed from the gem index, but the file was still published, so you'd still be able to install it. Now the gems are deleted, eliminating that option. So, other systems are definitely susceptible and it does burn people. I just don't think we've seen an issue on this scale yet. The largest I've hit have been when the twitter gem was yanked in advance of Twitter's shutdown, a fog-XYZ gem being yanked as new versions were released, and at least one yanked version of net-ssh. The only really effective way to avoid this is to mirror all your dependencies yourself (and not honor upstream yanks) or vendor all your gems. I know of exceedingly few people doing this. I've yet to encounter a legitimate cause for a yanked gem. But I worry more that a bad actor gains credentials to a high profile account and just wreaks havoc on the ecosystem. On that note, I have found and reported users that've committed their RubyGems.org credentials to GitHub in a "dotfiles" repository.