SEERM #4821
while looking into what it would take to fix bug 4821, I found that there are no specs
for any of the other methods in command dispatcher. I have attempted to add stubs for a
few of the methods and tested a few of the help outputs.
[#47720609]
Msf::PayloadSet#add_module does NOT return an annotated module class as
Msf::ModuleSet#add_module does because a payload module is defined as a
ruby Module instead of a ruby Class. Since add_module doesn't always
return an annotated_class, the logic in
Msf::ModuleManager#on_module_load needed to change to NOT use
annotated_class and create #add_module as return [void]. Thus, it is
necessary to pass in all the metasploit module metadata to
Msf::ModuleManager#cache_in_memory instead of assuming they can be
derived from the (payload) Module or (other) Class.
[#47720609]
Msf::ModuleManager#module_info_by_path was not being updated when a
module was loaded, so if a load_module was called again, say during
start up of prosvc, the module would reload even though there was no
change in the file because file_changed? couldn't find an entry for the
module's path in module_info_by_path.
[#47720609]
Fix some docs and variable names to make it clearer when methods are
expecting module instance and module classes. Change some 'name'
variables to 'reference_name' since that's the proper terminology.
[#50179803]
[SeeRM #7967]
[SeeRM #7870]
Because metasploit-framework runs migrations with the same process and
with the same connection as it later accesses the database, the column
information can become cached prematurely and be incorrect by the end of
the migrations. Fix the bad cache by automatically resetting the column
information for all model classes after the migrations have run.
[#50179803]
Move Msf::DBManager#migrate and the migrated attribute to
Msf::DBManager::Migration module to lower complexity of db_manager.rb
and in preparation for more migration related code on this branch.
[#49858419]
[SEERM #7958]
metasploit_data_models 0.14.3 relaxes the validation on
Mdm::Module::Detail#stance so it only needs to be in
Mdm::Module::Detail::STANCES if Mdm::Module::Detail#mtype is 'auxiliary'
or 'exploit' as framework only supplies a stance for those types when
using Mdm::Module::Detail.
[#47979793]
[#48414569]
Even though using Timecop locally on OS X makes the `should == <Time>`
work, it fails on travis-ci, so try using `should
be_within(1.second).of(<Time>)` instead.