[Fixes#38426061, #38097411]
Msf::Modules::Loader::Directory#read_module_content may calculate a non-existent
module_path that gets passed to File.open causing an Errno::ENOENT exception
to be raised when using the module cache with a module that has been
moved to a new path (as is the case that originally found this bug) or
deleted. Now, the exception is rescued and read_module_content returns
an empty string (''), which load_module detects with
module_content.empty? and returns earlier without attempting to module
eval the (empty) content.
As having Msf::Modules::Loader::Directory#read_module_content rescue the
exception, meant there was another place that needed to log and error
and store an error in Msf::ModuleManager#module_load_error_by_path, I
refactored the error reporting to call
Msf::Modules::Loader::Base#load_error, which handles writing to the log
and setting the Hash, so the error reporting is consistent across the
loaders.
The exception hierarchy was also refactored so that
namespace_module.metasploit_class now has an error raising counter-part:
namespace_module.metasploit_class! that can be used with
Msf::Modules::Loader::Base#load_error as it requires an exception, and
not just a string so the exception class, message, and backtrace can be
logged.
Depending on the kind of checkout, msfupdate should be smart about this.
This was first proposed by @corelanc0d3r I believe, but rejected because
it didn't seem to solve any immediate problem. Now, it does, as we are
ditching SVN Real Soon Now for performance reasons.
This change is minimal functionality and doesn't handle switching over
from one to the other.
nmonkee
Tod Beardsley
Luke Imhoff
corelanc0d3r
Brandon McCann
jvazquez-r7
HD Moore
David Maloney
James Lee