RubyGems.org gem replacement security vulnerability and mitigation

In this context "unsafe" only means not 100% verified.

I think we should ask the gem owner to verify that everything is ok unless there's a new version. I updated the script to report if there is a new safe version available.

Sigh, I know that it's easy to paint an outside group of programmers as incompetent fools who choose to ignore the Obvious Solutions(tm), but how many times must this be discussed before people realize that distribution package managers cannot replace the language-specific package systems? Language-specific package systems have requirements which distribution package managers like apt/dpkg, rpm/yum, pacman etc do not fulfill.

Just to name a few requirements:

- OS-independent. It's great that your package manager works well with your OS, but as a developer I want to target all my users, not just one OS. Nor do I want to make a bazillion packages for different OSes which takes a lot of time. I know that a lot of people have this attitude of "no, make a package for MY OS, I don't care about other OSes or how difficult it is for you", but this sort of "my way or the highway" unemphatic attitude is unhelpful. Clearly developers have chosen the highway.

- Ability to release outside OS package management schedules. I don't want users to wait half a year for the next distribution release before they can use the latest version of my app/library. Yes, some of you are using rolling release distributions, but that doesn't help developers because not all users are on rolling release distributions.

- Non-root installs.

- Ability to install multiple versions in parallel. RPM and DPKG do it by suffixing a version number in the package name but this is kind of hacky, we need real support.

I'm sure some package managers (maybe Nix? Guix?) can do the above but they came too late, there's too little momentum.

So why didn't Ruby/Node/Python etc developers adapt RPM/DPKG/etc? A few reasons include:

- Arcane, or complete lack of, documentation. Try to make a Debian package. It's a nightmare: the documentation is scattered all over the place, throws arcane terms at you as if you should have known them for a decade, and doesn't explain basic concepts very well.

- Many OS package managers are written in C. Many Ruby/Node/Python do not know C (or know it well).

- Lack of understanding of the problem domain. Here I give you some credit. When writing language-specific package managers, the authors probably did not fully understand the problem domain in the beginning. If they did, they might have looked at OS package managers more (or at least learned more lessons from them). But the aforementioned problems still stand.

Don't even get me started on Make. Make has its own set of problems.

There is another more detailed answer but the first thing you learn when programming with Ruby, Node and Python is that you can't rely on the distributions.

I give examples with Ruby: distributions have ridiculously out of date versions of the interpreter and sometimes they don't have what you need at all.

Suppose I want jruby on a Ubuntu 12.04 LTS

    $ apt-cache show jruby
    ...
    Version: 1.5.6-2
    ...

According to "rvm list remote" jruby is at version jruby-9.0.5.0 (9 followed 1.7).

Now suppose I want mruby.

    $ apt-cache show mruby
    N: Unable to locate package mruby
    E: No packages found

Ops!

Now, is this because the distributions don't have time to package and update interpreters and a zillion of gems or because their authors are not collaborative enough? This enters the realm of the other answer. Given the current status the only solution is bypassing the distros completely. I use them only for the OS, I get dev tools from their own repositories, whatever they are.