I know this is probably a very tricky issue, but watching dominictarr/event-stream#116 unfold makes me realise how damaging such an issue can be.

I know from experience that people who no longer maintain gems are often willing to give up ownership.

I wonder if there is a way to minimise the impact of these issues.

For example:

• Incorporating web-of-trust ideas into RubyGems.
• Validated organisations (e.g. I trust all gems in the Amazon/AWS organisations).
• Stable/trusted packages: A Gemfile could specify a certain level of "trustworthiness" required, and gems could receive vetting from the community.
• Better handling of gems which are no longer maintained - e.g. if a new author is added, it is immediately quarantined (such that bundle update won't use it by default).
• Automatic detection of suspicious code.
• Allow gems to be archived or otherwise marked as inactive.
• Perhaps mark gems older than 5 years with no activity as archived/inactive by default. Don't show these results in searches by default. Perhaps consider after a time to completely delete/remove these gems to free up namespace, but taking into consideration that existing users of such gems (if any) would get an explicit warning about changes.
  • N.B. this already occurs, but manually. Several times I've asked users to give up valuable "names", had a favourable response, yanked all old versions, and released new code. I believe it would be prudent for users of the "old" gem to receive some kind of warning/error - although in many cases this number is going to be 0 or very close to it, excepting malicious behaviour.
• Define a set of rules for "secure" dependency versions, e.g. only allow explicit versions = x.y.z or "~> x.y". Require a minimum ruby version to be specified. Identify and design characteristics which limit security issues and use then as a minimum water mark for "trustworthiness".
• Consider whether it's possible to incorporate static security checking tools into trustworthiness evaluation. There are tools for native executables which can detected a wide range of issues, additionally, code-level analysis (checking for eval) might help. Although, Ruby makes this pretty difficult. Maybe Ruby itself needs to provide more security at the interpreter level.

I know this is an impossible problem, but it would probably make sense to raise the bar as high as possible by default, and people who explicitly opt out are accepting those risks.

One aspect of this which I think could be developed further, is the idea of commercial organisations. Normally open source code has no warranty, but some authors might like to say "I guarantee my organisation and the following dependencies/versions are safe/have been checked" and that could be a paid service or managed in a more commercial way in order to facilitate the effort required for checking/vetting packages. You could basically add this trust to your project (i.e. you pay for the secure token/key, add it to your project, and then bundle update will only update things that are explicitly trusted).