Does rubygems.org do basic sanity checks on uploaded Gems?

[ChrLau]

Hi, I encountered a situation which I want to understand. We just started our tests with switching to Puppet 8 (from Puppet 7) and encountered a problem with the colored2 gem. Version 4.0.0 of that gem is missing the read right for "others". Due to this r10k (version 5.0.0) ran into an error (LoadModule error with colored2 version 4.0.0).
This lead to failures in our GitLab pipelines in the pre-receive hook where we are validating the Puppetfile syntax and other things.

During troubleshooting I found an issue (opened just 14 hours prior our encounter with that particular error), describing exactly our problem: colord2, #11: Require issue reintroduced in 4.0.0.
Ok, great. With 2 simple "chmod o+r ..." commands we fixed our problem.
As we installed the gem as root via Puppets bundled ruby interpreter /opt/puppetlabs/puppet/bin/gem the gem files had root:root as owner/group.
Hence leading to our LoadModule problem due to missing filerights.

However there is one thing which I still don't fully understand. Or maybe I just had a misconception about what rubygems.org is/does.
Version 4.0.0 of colored2 was released August 24th, 2023. The missing read rights for others are present in the data.tar.gz of the gemfile since that day.
The r10k gem in version 5.0.0 listes the colored2 dependency as "~> 4.0.0". Therefore a downgrade to colored2 3.1.2 is not an option.

This should, in my understanding mean, that no r10k installation should have worked, ever.
(Yes, it is more of a file rights and ownership issue, so potentially there are enough scenarios where this will work without issues.)
Yet the first issue for this gem build error was just created on January 7th, 2025.

Why is that so? Granted I do know that many Linux distributions packages Ruby Gems on their own so they are installable via apt, aur, yum, etc. And they, most likely, fixed that error.
But there is also no issue from distribution maintainers to upstream about that error.

Additionally I was under the impression that rubygems.org does some basic checks on any uploaded gem.
But this occurrence made me question that. I checked all documentation about uploading gems, etc. And couldn't find anything specific about this, therefore I assume my mind just made that up.

And yes, there are other ways to get a gem on system apart from gem install which could also circumvent the problems.

Yet I'm still wondering: How? Does rubygems.org really not do any sanity checks on uploaded gems?
Mind: This is not meant to put blame on anyone. I just want to solve some knots in my head.

Also I'm very well aware of the bystander effect and other social behaviours which can lead to problems being unreported for quite a long time.
In my work life I had plenty of those "How did this ever work!?" moments.

All in all I'm just curious to understand how such an error can go unreported for so long. 😄