MSP-11147
Merge to get framework instance cleanup, which should clean up a lot of
thread leaks too.
Conflicts:
Rakefile
lib/metasploit/framework/spec.rb
spec/spec_helper.rb
MSP-11130
Fail `rake spec` if
`Metasploit::Framework::Spec::Constants::Each.configure!`'s
`before(:each)` does not clean all leaked constants and if should be
removed so that it does not interefore with future specs.
MSP-11130
`Metasploit::Framework::Spec::Constants::Suite` extracts out
`LOG_PATHNAME`, `configure!`, and `define_task` as those piece are
specific to handling constant leaks for the entire suite. This is in
preparation for `Metasploit::Framework::Spec::Constants::Each`.
MSP-11130
Instead of printing the leaked constants to stderr, log them to
`log/leaked-constants.log`. In task action for spec, read
`log/leaked-constants.log`. If it exists, print each leaked constants
(and it appropriate it's module full name) and then exit with 1. If the
file does not exist, do nothing.
MSP-11145
Extract the spec task action which errored out if
`log/untested-payloads.log` exists to
`Metasploit::Framework::Spec::UntestedPayloads.define_task`.
MSP-11145
Add action to spec task that will cause spec to exit(1) if
log/untested-payloads.log exists. The untested payloads are then
printed with instructions of which spec to update.
MSP-10905
Require in Rakefile so that db tasks are defined. Make it optionally so
that `rake` doesn't error out when metasploit-framework installed with
`bundle install --without db`.
MSP-9606
In order to support Metasploit::Credential correctly,
metasploit-framework needs to support Metasploit::Concern, which does
all its magic using a Rails::Engine initializer, so the easiest path is
to make metasploit-framework be able to use Rails::Engines. To make
Rails::Engine use Rails::Engine, make a dummy Rails::Application
subclass so that all the initializers will be run when anything requires
msfenv.
[#46224565]
The following rake tasks are added and work similar to how they work in
rails apps:
* db:create
* db:drop
* db:migrate
* db:migrate:status
* db:rollback
* db:schema:dump
* db:schema:load
* db:seed (but no db seeds defined at this time)
* db:setup
* db:version
The hidden task db:test:prepare is also available, which means `rake
spec` can depend on it so that the test database is dropped and
recreated from the development database when running specs (Although
there are yet to be database tests, this branch is in preparation for
that work that will be split between multiple developers.)
[#45771305]
MetasploitDataModels 0.6.1 adds a re-usable yard.rake so that all
Metasploit project don't have to define their own. It also adds guards
so that the YARD tasks aren't defined (and don't cause errors) if YARD
is not available.
This also adds support for making the Rakefile work with `bundle install
--without development test` so it still functions in the bundle building
environment for Pro.
I missed a spot where I referenced the nested_paths as nested_pathnams
after I renamed the variable. Now, Msf::ModuleManager#add_module_paths
has rspec tests.
Rspec can be invoked with `rake` as the default task or `rake spec`
explicitly.
I changed RuntimeError to ArgumentError since that error was more
specific to having a bad argument error. I adding missing dependencies
to the Gemfile and a require to msf/core/db_manager.rb where it errored
out trying to access Msf::Config when I just did require 'msf/core' in
the spec.
[Fixes#36737359]
Refactor Msf::ModuleManager into concerns so its easier to understand and
duplicate code can be made DRY. The refactoring also ensures that when
loading from directories, Fastlibs, or reloading, the wrapper module will
always be named so that activesupport/dependencies will function.
darkbushido
Luke Imhoff
Samuel Huckins
Brandon Turner
James Lee