Thanks for this. I did some extra work on it (via someone else's fork) so it can run across multiple directories. I've too many projects lurking around to cd into all of them! I added some pretty colours too :)
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.
Reliable, secure package management systems have existed for a long time [1] [2] [3]. Ruby, Node, Python, et al. just choose to ignore them, just like they choose to ignore other proven development tools [4].
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.
Thanks for your excellent reply.
Do you think support for Nix, Guix etc will increase, or will reliable package systems only become more fragmented?
I do remember seeing a Linux variant announce they had achieved full trusted compilation a while back (on HN), which was pleasant to see but sadly too rare.
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.
Anyone know why the date listed for a gem listed on rubygems.org wouldn't match the contents of the gem? I am guessing possible timezone differences. But some clarification would be nice.
For example:
Listed for bundler -v 1.11.2 - December 16, 2015 (257 KB)
$ tar tvf bundler-1.11.2.gem
-r--r--r-- 0 wheel wheel 2161 Dec 15 19:12 metadata.gz
-r--r--r-- 0 wheel wheel 257198 Dec 15 19:12 data.tar.gz
-r--r--r-- 0 wheel wheel 267 Dec 15 19:12 checksums.yaml.gz
The manual verification steps are basically impossible for any non-trivial gem. I wonder if it would be possible to re-build (from git) the impacted gem versions and check their checksum against the downloaded version to detect differences?
To save app developers manually trawling dozens of gems and duplicating work, we need to have somewhere that people can publicly disclose gems they've found to be compromised.
