The auxiliary report mixin overrides some of the methods in
Metasploit::Credential, which is fine in framework, but causes issues in
projects relying on the base behavior of Metasploit::Credential. This
changes the include scope from global to just whatever includes the
external module mixin.
Changes from a "hope we get at most one message at a time" model to
something beginning to resemble a state machine. Also logs error output
and fails the MSF module when the external module fails.
Came up on Twitter, where Justin may have been trolling a little:
https://twitter.com/jstnkndy/status/798671298302017536
We have a `print_good` method, but not a `print_bad`, which seems a
little weird for Ruby -- opposite methods should be intuitive as Justin
is implying.
Anyway, I went with alias_method, thanks to the compelling argument at
https://github.com/bbatsov/ruby-style-guide#alias-method
...since Metasploit is all about the singleton, and didn't want to risk
some unexpected scoping thing.
Also dang, we define the `print_` methods like fifty billion times!
Really should fix that some day.
The merge_check_key method (found in Msf::Module::ModuleInfo)) uses
respond_to? to check is our object includes a merge_info_description
method before merging descriptions. The respond_to? method in 2.1.4
by default no longer checks private and protected methods, and this
is breaking our merge_check_key method.
Fix#4163
MSP-11126
Fully-qualify `Msf::MODULE_TYPES`, `Msf::MODULE_ANY`,
Msf::MODULE_ENCODER`, `Msf::MODULE_EXPLOIT`, `Msf::MODULE_NOP`,
`Msf::MODULE_AUX`, `Msf::MODULE_PAYLOAD`, `Msf::MODULE_POST` so that
their usage isn't dependent on nested lexical scoping.
MSP-11126
`Msf::Module::Author` was already aliased to `Msf::Author`. This just
moved `Msf::Module::Author` to that alias to free up
`Msf::Module::Author` so it can be used for a concern for
`Msf::Module`'s author methods.
Matthew Kienow