Don't hardcode specific versions in Gemfile

[rhertzog]

Hello, I'm trying to improve the beef-xss package for Kali and in the process I want to use system-wide ruby gems provided by proper debian packages. I packaged most of the required gems but when I do that I package the latest version of each gem (or keep the version already available in Kali, which on the contrary might be older than the one that you are requiring).

Please fix the Gemfile to avoid exact version requirements (like you do on eventmachine, sinatra, rack and now rubydns) and favor relationships that matches the reality of beef-xss requirements (i.e. >= a specific minimal version that is required). FWIW Kali still has evenmachine 0.12, rack 1.4.1, sinatra 1.3.2. Do you know if beef works with them?

Furthermore you have some "~>" relationship that imposes to use an older version. em-websocket for instance is locked to 0.3.X while we now have 0.5.1 in Kali. Would beef work with 0.5.1 ?

In general, it's best to assume that the code will continue to work with new versions of the gems unless you have prior experience with a specific gem breaking backwards compatibility all the time (or if the upstream author announced a clear versioning scheme reflecting the compatibility breaks).

[bw-z]

Hi @rhertzog thanks for the feedback, I have a version of the gemfile as you suggested for testing here; https://github.com/beefproject/beef/blob/gemfileupdates/Gemfile

@antisnatchor is there a reason you locked the em-websocket to 0.3.x and would you be ok to bump this up? I have done some testing up to 5.1 it looks ok to upgrade.

[rhertzog]

@bw-z thanks! You still use "~>" for uglifier where we have version 2.5.0 (newer than 2.2.X) and also for rubydns.

Do you know if beef works with eventmatchine 0.12, rack 1.4.1, sinatra 1.3.2 ? Because we have those versions in Kali currently and they are older than the minimal version that you require. If the dependency is real, I'll update them but sometimes the dependency is increased without reason and wanted to ensure that it would not work with the old versions.

[antisnatchor]

Hey @rhertzog

We can't use the eventmachine version you mentioned, as it's too old (2009).
We need the latest version 1.0.3 for obvious performance reasons.

Rack/Sinatra -> same reason. Also, old versions of these two gems were vulnerable to security bugs.

I don't see why we can't have multiple versions of a gem?

Also, I never understood why in Kali you don't give to the user an RVM default setup, maybe installed as root, so you can use multiple ruby versions without any issues.

[rhertzog]

I was more interested in whether API changes would break compatibility with those old versions... but thanks for your answers anyway.

For your other comments: Packages in Debian stable, even if they are sometimes old, get relevant security patches applied.

Multiple versions of a gem are not supported in official debian packages. Speaking of security support, supporting one versions is enough work already.

Software installed with RVM will not get updates via the standard packaging system so while it's available, we won't use it for official packages. Again it's unmanageable from a security point of view.

[soh-cah-toa]

Hey Raphaël,

The RubyDNS requirement had to be set at 0.7.x due to some considerable API changes. From what I can tell about the latest 0.8.x version, it looks like the API changes do not affect us but I haven't confirmed this. The compatibility history for this gem is pretty significant; regularly breaking compatibility with previous versions. I'd be a little nervous if it wasn't future-proofed with ~>.

[wadealcorn]

@antisnatchor are you able to confirm any issues with upgrading this gem?

[xntrik]

I also believe we should start shifting the Gemfile.lock into the distribution. I'm aware we ran into some issues with this in the past, but, my understanding of Bundler is that you're meant to commit the lock file too, as this is used to keep all the devs/environments using the same set of Gems. This is discussed in the top FAQ here http://bundler.io/v1.9/faq.html ..

[ioquatix]

RubyDNS 1.x is stable.

[frenchi]

+1 to commiting Gemfile.lock. That's what it's there for.

On Monday, 30 November 2015, Samuel Williams [email protected]
wrote:

RubyDNS 1.x is stable.

—
Reply to this email directly or view it on GitHub
#1025 (comment).

Sent from Gmail Mobile

[bcoles]

Gemfile.lock is now included with BeEF.

Several gems still make use of hard-coded versions:

• #gem 'twitter', '>= 5.0.0' # Twitter Notifications extension
• gem 'rubyzip', '>= 1.0.0'
• gem 'rubydns', '0.7.0' # DNS extension
• gem 'therubyracer', '~> 0.11.0beta1' # Windows support
• gem 'therubyracer', '0.11.3' # Mac support
• gem 'rest-client', '>= 1.8.0' # tests

The therubyracer gems are probably acceptable for now. The twitter, rubyzip, andrest-clientgems make use of>=` which is acceptable. Also, the Twitter extension likely no longer works and the dependency is commented out.

The rubydns gem should be reviewed.

[bcoles]

Closing this issue.

All gem version requirements now make use of >= with the following exceptions:

# Required for Linux
if RUBY_PLATFORM.downcase.include?('linux')
  gem 'therubyracer', '~> 0.12.2', '<= 0.12.2'
end

# DNS extension - limited to 0.x
# backwards-compatibility breaking changes in 1.x and again in 2.x
group :ext_dns do
  gem 'rubydns', '~> 0.7.3'
end

# Rack 2.x is not supported yet. To be updated to 2.x, as per #1424
gem 'rack', '~> 1.6.5'