Dependabot vulnerability in Gem rack < 2.1.4

Help
1

I trying to update gem ( see: Releases · rack/rack · GitHub )

TerminalAddict,
We found a vulnerable dependency in a repository you have security alert access to.

TerminalAddict/repo-name
Known high severity security vulnerability detected in rack < 2.1.4 defined in Gemfile.lock.
You have Dependabot security updates enabled, so we are attempting to create a pull request to update the vulnerable dependency

I edit Gemfile.lock
it was rack (1.6.13), I update to rack (2.2.3)
then I do
bundle update --all
output: Using rack 1.6.13 (was 2.2.3)

Anybody know how to deal with this Dependabot vulnerability ?

2

Can you share a link to your repo?

Can you share more output from your command?

I might be that one of your dependencies in Gemfile needs 1.6.13 and it is downgrading it.

So I would recommend updating gem versions in your Gemfile, delete your Gemfile.lock file and then run bundle install for a clean install.

3

Hey man,

cat Gemfile
source 'https://rubygems.org'

# gem 'jekyll'
gem "jekyll", github: "jekyll/jekyll"

group :jekyll_plugins do
  gem 'jekyll-sitemap'
  gem 'jekyll-feed'
  gem 'jekyll-seo-tag'
  gem 'jekyll-paginate-v2', git: 'https://github.com/TerminalAddict/jekyll-paginate-terminaladdict'
  gem 'jekyll-assets'
  gem 'jekyll-archives', git: 'https://github.com/jekyll/jekyll-archives'
  gem 'uglifier'
end

I deleted Gemfile.lock, then run bundle install
Afterwards:

grep rack Gemfile.lock
    rack (1.6.13)
      rack (~> 1.0)

So yeah, there is definitely a dependency there, I’m just not sure where

4

not sure if this could help? I think this is a list of installed gems that use rack

paul@spyro:~/gems/gems$ grep -R \'rack\' *  | grep -v ^rack
addressable-2.6.0/Gemfile:    gem 'rack', '< 2', :require => false
addressable-2.6.0/Gemfile:    gem 'rack', :require => false
addressable-2.7.0/Gemfile:    gem 'rack', '< 2', :require => false
addressable-2.7.0/Gemfile:    gem 'rack', :require => false
bundler-2.1.4/man/bundle-open.ronn:    bundle open 'rack'
bundler-2.1.4/man/bundle-open.ronn:Will open the source directory for the 'rack' gem in your bundle.
bundler-2.1.4/man/bundle-inject.ronn:    bundle inject 'rack' '> 0'
bundler-2.1.4/man/bundle-inject.ronn:This will inject the 'rack' gem with a version greater than 0 in your
bundler-2.1.4/man/bundle-open.1.txt:       bundle open 'rack'
bundler-2.1.4/man/bundle-open.1.txt:       Will open the source directory for the 'rack' gem in your bundle.
bundler-2.1.4/man/bundle-inject.1.txt:     bundle inject 'rack' '> 0'
bundler-2.1.4/man/bundle-inject.1.txt:       This  will  inject the 'rack' gem with a version greater than 0 in your
bundler-2.2.2/lib/bundler/man/bundle-open.1.ronn:    bundle open 'rack'
bundler-2.2.2/lib/bundler/man/bundle-open.1.ronn:Will open the source directory for the 'rack' gem in your bundle.
bundler-2.2.2/lib/bundler/man/bundle-inject.1.ronn:    bundle inject 'rack' '> 0'
bundler-2.2.2/lib/bundler/man/bundle-inject.1.ronn:This will inject the 'rack' gem with a version greater than 0 in your
rubygems-update-3.2.2/bundler/lib/bundler/man/bundle-open.1.ronn:    bundle open 'rack'
rubygems-update-3.2.2/bundler/lib/bundler/man/bundle-open.1.ronn:Will open the source directory for the 'rack' gem in your bundle.
rubygems-update-3.2.2/bundler/lib/bundler/man/bundle-inject.1.ronn:    bundle inject 'rack' '> 0'
rubygems-update-3.2.2/bundler/lib/bundler/man/bundle-inject.1.ronn:This will inject the 'rack' gem with a version greater than 0 in your
5

You lost the tree by using a grep. Doing a find on your Gemfile.lock I saw that sprockets forces rack to be < 2.

sprockets (2.12.5)
  hike (~> 1.2)
  multi_json (~> 1.0)
  rack (~> 1.0)

And then searching for sprockets

jekyll-assets (1.0.0)
      ...
      sprockets (~> 2.10)

I see that is caused by jekyll-assets.

You have 1.0.0 but the latest is 3.0.12 on GH releases or RubyGems where you can see it uses sprockets 4 (up from you current 2)

You don’t pin jekyll-assets in your Gemfile. :confused:

If you run bundle install without lockfile, you should get the latest jekyll-assets.

You can also try in your Gemfile and that might be more verbose to say that target 3 is not compatible with other gems

gem install 'jekyll-assets', '~> 3.0'
6

This gives you the bleeding edge jekyll on GitHub even it hasn’t been tagged and released

You can restrict published releases like this which is >= 4.2, < 5

gem "jekyll", "~> 4.2"
7

What you shared is for addressable which is not in your lockfile so not in your project. Just in your user-level gems in ~/gems.

The other matches are in bundler itself and rubygems’ bundler section. Neither should affect your ability to upgrade rack.

8

Hey Michael, thanks for your help :slight_smile:

I don’t know what this means?
as above I have a simple gem ‘jekyll-assets’ in my Gemfile.
I can manually install jekyll-assets

gem install jekyll-assets
Successfully installed jekyll-assets-3.0.12

I can also remove the gemfile.lock of course, but as soon as I bundle install everything reverts back to jekyll-assets 1.0.0

Using jekyll 4.2.0 from https://github.com/jekyll/jekyll.git (at master@ca03e7a)
Using jekyll-archives 2.2.1 from https://github.com/jekyll/jekyll-archives (at master@9d3d3cb)
Using jekyll-assets 1.0.0

So nope, that didn’t do it :cry:

update: I’ve just found something

jekyll-assets (~> 3.0) x86_64-linux was resolved to 3.0.12, which depends on
      jekyll (>= 3.5, < 4.0)

Which brings me back to a previous statement … I don’t understand what “pinning” means.

I’m going to raise an issue on GH with jekyll-assets I think

9

and in my “system administrators” mind, downgrading Jekyll to version 4.0.0 seems like a step backwards :stuck_out_tongue: :laughing:

10

Pinning is locking

In Gemfile, which is a ruby script:

# Unpinned, ie free floating. Unpredictable 
gem 'jekyll-assets'

# Pinned. Locked within a range.
gem 'jekyll-assets', '~> 3.0'

You can run the gem command in the shell but that is for system or user level gems.
Since you are dealing with a project level of gems, you want to make sure you run

bundle install

And that will run your gem install lines for you, from the Gemfile

11

Ah right … so I did that, which led me to:

jekyll-assets (~> 3.0) x86_64-linux was resolved to 3.0.12, which depends on
      jekyll (>= 3.5, < 4.0)
12

Yes you are right. The RubyGems listing says it needs Jekyll < 4.0

I find that is okay. The main benefit for me for Jekyll 4 is the cache for building means by 1 minute build on 3.9 became like 1 second. Plus you can use the link liquid tag without prefacing it with {{ site.baseurl }} - that is the only material thing to adjust for when I switch.
Well there are some more Jekyll 4 only features I came across, but I didn’t get into them and I do fine without them.

13

See if the gem is maintained and if there are any issues about Jekyll 4 support. Maybe it is simple, maybe complicated. Maybe there are forks which support Jekyll 4.

14

thanks man ! you’re awesome.
Yep been googling all morning, and have just submitted:

15

I guess I could always do:

gem 'jekyll-assets', github: "envygeeks/jekyll-assets"

in my gemfile … right??

16

Indeed, yes you can use that and you’ll get the latest on master which does support jekyll 4 according to the gemspec file.