Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RubyGems.org gem replacement security vulnerability and mitigation

blog.rubygems.org

Post reply on HN
Print view View original

11–20 of 24 posts

Re: RubyGems.org gem replacement security vulnerability and mitigation

#12

Post by pmontra »

colanderman wrote: post #7
hellbanner wrote: post #6

Great response. It's still sad to me in 2016 we don't have reliable build systems for otherwise such modern programming tools. I understand why .. just sad. Great job on the investigation though.

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]. [1] https://debian-handbook.info/browse/stable/sect.package-auth... [2] https://access.redhat.com/security/team/key/ [3] https://wiki.archlinux.org/index.php/DeveloperWiki:Package_s... [4] https://en.wikipedia.o…

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.

Re: RubyGems.org gem replacement security vulnerability and mitigation

#15

Post by symtos »

FooBarWidget wrote: post #8
colanderman wrote: post #7

Earlier quoted context omitted.

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]. [1] https://debian-handbook.info/browse/stable/sect.package-auth... [2] https://access.redhat.com/security/team/key/ [3] https://wiki.archlinux.org/index.php/DeveloperWiki:Package_s... [4] https://en.wikipedia.o…

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…

And how many times must central repositories be compromised, and vulnerabilities such as this one be disclosed, before people start to realize that /completely/ ignoring the progress of the well-known package managers and how they implemented mandatory signing over a decade ago (with some exceptions), is nothing short of negligent?

Re: RubyGems.org gem replacement security vulnerability and mitigation

#16

Post by revorad »

dcu wrote: post #4

I just wrote a simple script to check the gems: https://gist.github.com/dcu/3c06e4ab0e98158c5742c4fd2b31523d

Thanks for this. So I ran this and found a bunch of unsafe gems. Do I report them to each gem author or to RubyGems security?

Re: RubyGems.org gem replacement security vulnerability and mitigation

#17

Post by davidradcliffe »

revorad wrote: post #16
dcu wrote: post #4

I just wrote a simple script to check the gems: https://gist.github.com/dcu/3c06e4ab0e98158c5742c4fd2b31523d

Thanks for this. So I ran this and found a bunch of unsafe gems. Do I report them to each gem author or to RubyGems security?

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

Re: RubyGems.org gem replacement security vulnerability and mitigation

#18

Post by davidradcliffe »

seanhandley wrote: post #9

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.

If anyone finds compromised gems they should report them to the RubyGems.org security team immediately.

Re: RubyGems.org gem replacement security vulnerability and mitigation

#19

Post by quakershake »

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

Re: RubyGems.org gem replacement security vulnerability and mitigation

#20

Post by quakershake »

quakershake wrote: post #19

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 w…

I've also noticed that there are gems listed on rubygems.org that have dates in the past relative to the gem contents.

Nevermind - its the date in the gem spec

Post reply on HN