Semi related CVEs aside (CVE-2013-0333 and CVE-2013-0156): YAML's security problems have been known for years by the community. YAML aside, don't trust user input. This is egg on rubygems's face and the ruby community. I don't think http://rubycentral.org/ has full-time staff for rubygems either.

Gems, specifically should be signed. They are not, this type of exploit will continue to happen, hell, remember when github screwed up ssh keys? Who knows what's in the ecosystem.

TL;DR; Ruby's security ecosystem is butter.

Disclaimer: I love ruby and use it daily. It was two critical problems IMO: unsigned code and GIL. Yes, GIL. I'm looking at you ruby-core.

The GIL is not really a problem. There are far more pressing issues with MRI, and many core developers are working hard to solve these.

Like what? I thought the GIL and GC forcing COW were the largest problems bar none.

How would signing gems have prevented this situation?

It would allow you to verify the authenticity of the gems, even if the server had been compromised.

(This isn't a new technique -- for example, .deb packages distributed through APT are usually signed with gpg -- IIRC, this was a measure introduced years ago in response to a Debian mirror being compromised.)

(my knowledge is circa early 2000s)

Debian has (had?) a high barrier to entry to become a developer, and every developer signs their packages. The release binaries are arranged on a secured box and the release key itself is held by a limited set of people.

In short, the signatures work because of the human element and organizational structure of Debian.

Rubygems accepts submissions from the general public.

So, again, I don't see how it would have helped.