ruby 2.6.1

[firefart]

This adds support for ruby 2.6

https://www.ruby-lang.org/en/news/2018/12/25/ruby-2-6-0-released/

https://www.ruby-lang.org/en/news/2019/01/30/ruby-2-6-1-released/

[firefart]

BTW rubocop still targets ruby 2.2 (https://github.com/rapid7/metasploit-framework/blob/master/.rubocop.yml#L12).

We might change this in the future but it can have implications on distros like kali and such as they might not have the required ruby version installed

[bcoles]

We might change this in the future but it can have implications on distros like kali and such as they might not have the required ruby version installed

Kali Rolling has supported Ruby 2.5 default since ~2017.

[acammack-r7]

Gonna mark this as delayed for the moment until we have a chance to address the possibility of breaking changes.

[firefart]

@acammack-r7 there should be no breaking changes on this one. The stuff discussed above is a separate issue

[busterb]

This should only affect what version of Ruby developers test when building Metasploit. Distributions like Kali, Pro, Omnibus, etc. all use their own locally-specified Ruby anyway. In other words, this just forces developers and folks following on github to possibly update if they're using a Ruby version manager that honors .ruby-version.

There's an argument that the sooner we start testing, the sooner we'll be ready when a distro bumps versions. However, #7814 is an example of when we weren't ready before a distro switched, even though we started early (It took 4 months (#7819) to get all of the upstream gems sorted out). #10699 is an example of a surprise Ruby 2.5-related bug (#10177 (comment)) that still took about 9 months to identify and fix from release. So no guarantees it'll be any easier this time around, whether we bump now or wait.

So, I'll ask, what did we want to address before we started testing Ruby 2.6 with this PR? Debian (and therefore Kali Rolling, etc.) switched to 2.5 March 4th last year, for reference: https://lists.debian.org/debian-ruby/2018/03/msg00013.html

@anthraxx any thoughts on the schedule for ArchLinux?

[anthraxx]

In Arch you can expect bumps ASAP. In fact ruby 2.6 is already in staging and dependencies are handled and rebuild: https://www.archlinux.org/packages/staging/x86_64/ruby/ There are always distros that are highly conservative but it certainly helps distros who are rolling and keep up with what exists today instead of in the past.

[acammack-r7]

@busterb I don't think this will be as big a deal as, say, the 2.4 release, but there have been a lot of internal changes to the Ruby VM and I at least want a full test run on 2.6 before bumping in tree. There's nothing stopping people from bumping their local .ruby-version and trying it out themselves (I, for example, am having a hard time building nokogiri 1.8.5, which I installed just fine on 2.5.3 yesterday).

[sempervictus]

While I am a fan of "the faster we update the faster we catch bugs," the recent work @busterb did to fix pivot sockets due to an MRI change is a cautionary tale: its often not immediately visible that breakage happens at the interpreter level.
Would it be possible to rig the current CI infra to test against a few MRI versions so that we see regressions between PRs/branches as delineated by interpretater revision? Won't catch the pivot socket thing, but that was especially nasty...

[busterb]

I think I'm gonna move this forward, now that we got a lot of the other bundler 2.0 problems out of the way. Let me check with the vulndb folks to make sure it doesn't hose them.

[busterb]

We may need to add the travis-ci bits first, then switch .ruby-version in a second commit. I think there are some infrastructure things that aren't ready for .ruby-version to switch to 2.6.

[sempervictus]

I've got an rvm gemset build running at the office, will ping back results when I get back there, but Ill be using 2.6 if it builds and report any issues. Any spare time right now will be focused on getting http proxy landed and upstreaming http transport changes needed for DNS transports, but the jit is too compelling, and until @brixen gets his back, or truffle becomes usable, this looks like the best way to get complex metasm stuff to work in the handler window.

[sempervictus]

Seems to work, been playing with it any chance i get and leaving it running in the background to see if the JIT or anything else will leak/blow up... so far so good:

[*] [2019.01.27-05:27:21] 10.219.0.146:445 - Obtaining a service manager handle...
[*] [2019.01.27-05:27:21] 10.219.0.146:445 - Creating the service...
[+] [2019.01.27-05:27:23] 10.219.0.146:445 - Successfully created the service
[*] [2019.01.27-05:27:23] 10.219.0.146:445 - Changing service description...
[*] [2019.01.27-05:27:25] 10.219.0.146:445 - Starting the service...
[+] [2019.01.27-05:27:25] 10.219.0.146:445 - Service start timed out, OK if running a command or non-service executable...
[*] [2019.01.27-05:27:25] 10.219.0.146:445 - Removing the service...
[+] [2019.01.27-05:27:25] 10.219.0.146:445 - Successfully removed the service
[*] [2019.01.27-05:27:25] 10.219.0.146:445 - Closing service handle...
(2019-01-27)05:27 (S:0 J:6)msf  exploit(windows/smb/psexec) > ruby -v
[*] exec: ruby -v

ruby 2.6.0p0 (2018-12-25 revision 66547) [x86_64-linux]
(2019-01-27)05:27 (S:0 J:6)msf  exploit(windows/smb/psexec) >

[busterb]

Thanks for the update @sempervictus . We've locally been enjoying some kind of silly fallout from rubygems 2.5 / Bundler 2.x and other things tangentially-related to Ruby 2.6.

[firefart]

In the meantime :) https://www.ruby-lang.org/en/news/2019/01/30/ruby-2-6-1-released/

[firefart]

I just pushed updates to this branch so 2.6.1 is used

[sempervictus]

The actual fix for 2.6.1 seems pertinent to us...
Once we move up, might be worth revisiting Rex core libs and updating to use some of the new primitives, making things better for jit, etc.
Thanks @firefart

[busterb]

Could we add a patch like this so we don't get an annoying warning on startup? Unfortunately ruby/bigdecimal#115 will cause annoyance until we can get rid of rails 4.x in framework.

diff --git a/lib/msf/core.rb b/lib/msf/core.rb
index 35a702d3b1..f07bf40651 100644
--- a/lib/msf/core.rb
+++ b/lib/msf/core.rb
@@ -13,6 +13,12 @@
 # Include backported features for older versions of Ruby
 require 'backports'
 
+require 'bigdecimal'
+
+def BigDecimal.new(*args, **kwargs)
+  BigDecimal(*args, **kwargs)
+end
+
 # The framework-core depends on Rex
 require 'rex'
 require 'rex/ui'

[firefart]

@busterb added your code

[busterb]

Thanks. I'll land this and we'll keep an eye out for any regressions.

[busterb]

Release Notes

This adds initial Metasploit support for Ruby 2.6 and later.