Metasploit has released version 3.2 of the framework. This release is provided under the BSD license, which removes many of the packaging restrictions that applied to 3.0 and 3.1. The latest tarball is available from the metasploit web site.
reassigning to maintainer
Created attachment 173423 [details] New ebuild for metasploit 3.2 revision 5981
Ebuild seems to install ok, but: # msfcli3 ruby: no such file to load -- auto_gem (LoadError) So there's something messed up with ruby, most likely the deps (no surprise there ;) ) net-analyzer/metasploit-3.2 USE="-gtk -httpd -postgres -sqlite -sqlite3"
(In reply to comment #3) > Ebuild seems to install ok, but: > > # msfcli3 > ruby: no such file to load -- auto_gem (LoadError) auto_gem.rb is installed as part of rubygems in /usr/$(libdir)/ruby/site_ruby/auto_gem.rb and loaded through RUBYOPT environment variable set in /etc/env.d/10rubygems. My wild guess is that you are testing in a chroot that has RUBYOPT set but not rubygems installed?
From the ruby herd perspective I'm also voting for this version bump. The currently stable metasploit 3.1 version depends on dev-ruby/rails-1.2*, which we would like to remove from the tree due to its incompatibilities with ruby 1.8.7 and given the fact that upstream no longer provides security support for it. metasploit 3.2 depends on Rails 2.1, which does not have this issue. Note that the proposed ebuild by Erwin leaves the bundled copy present. From a security standpoint it may be better to remove it (in data/mfsweb/vendor/rails) and always use the system version.
3.2 uses a "frozen" copy of rails, but it still depends on rubygems. Removing this and using the system version might work, but please test it, as we monkey patch rails to work around some limitations. The auto_gem thing is a environment problem (remove -rautogem from ENV), not a code issue.
(In reply to comment #6) > 3.2 uses a "frozen" copy of rails, but it still depends on rubygems. Removing > this and using the system version might work, but please test it, as we monkey > patch rails to work around some limitations. I'll leave that decision to the metasploit maintainers. In any case the ebuild should be consistent: either depend on dev-ruby/rails-2.1* and remove vender/rails, or remove the dependency and use the bundled copy.
fwiw, my vote is remove the dependency, we are bundling rails for the forseeable future.
I was wondering, just like we can have an up-to-date repository ebuild of a specific program with 9999 as its version number, would it be possible to have an up-to-date revision ebuild, something like metasploit-3.2_p9999.ebuild patched someshat like this: 14,15c14,19 < MTSLPT_REV=${BASH_REMATCH[2]} < ESVN_REPO_URI="https://metasploit.com/svn/framework3/branches/framework-${PV%_p*}/@${MTSLPT_REV}" --- > if [[ "${PV}" =~ (_p)([9]+) ]] ; then > MTSLPT_REV="" > else > MTSLPT_REV=@${BASH_REMATCH[2]} > fi > ESVN_REPO_URI="https://metasploit.com/svn/framework3/branches/framework-${PV%_p*}/${MTSLPT_REV
Is it just me, or is the ebuild attachment listed above just a copy of the ebuild for metasploit 3.1?
it is (and it seems to work)
Oh, sorry. I assumed that the ebuild was intended to resolve things like the dependency on Ruby < 1.8.7. I'll just wait for an "official" update. :)
I thought so too ;) but for now, I just masked ruby version >= 1.8.7
We'll most likely move to mark ruby 1.8.7 stable at some point, so if there are issues with ruby 1.8.7 we should try to identify and resolve them. I know that metasploit 3.1_p5699-r1 is not compatible with ruby 1.8.7 due to its ruby version, but this should no longer be a problem for metasploit 3.2 since it uses an updated version. Please let us know if you detect other ruby 1.8.7 incompatibilities.
I was playing with this package this morning. I have just created a metasploit-3.2_p6432.ebuild with the block on ruby 1.8.7 removed, and have run an upgrade. I haven't had a chance to play with it yet to see if any problems rear their ugly heads, but I'll post back here if I run into anything. Given my somewhat limited knowledge of the intricacies of ebuilds, it does look like having a 3.2_p9999 ebuild that always updates to the HEAD revision would be good. Is there support for that, or a reason against it?
Sorry for lo-oong delay, guys. It's in the main tree.
