Open zeroSteiner opened 3 years ago
This is kinda my fault for asking to pull Rex out. Wanna assign me?
took a look over this, and it dawns on me that we have a bit of a logical absurdity here: logging is a core function of Rex, and itself depends on rex-sync
but lives inside lib/rex/logging
within Msf.
For a more "holistic" approach, i think we should actually move that subtree out of Msf, probably into rex-core
, since we already need that and sync
to use socket
. Thoughts?
Alternatively i can do some "magic" checks for whether logging is defined in the global namespace and if it isn't then create short stubs for API compatibility - AKA, hack it up some. :smile:
@zeroSteiner - could you please check to see if the linked PR in Core fixes this? I am not l33t enough to move those files w/ their history though.
The logging methods used by
rex-socket
are defined globally by the Metasploit Framework. Because theelog
function andLEV_3
constant is not defined withinrex-socket
it will crash when used outside of Metasploit.There are at least 4 instances:
The issue can be confirmed by triggering an error log. In the following scenario, the user creates a new
Rex::Socket::Parameters
instance and specifies anSSLCert
file that exists, but can not be read. This assumes you're not running as root of course.Fixing the
LogSource
reference:Since this gem isn't dependant on Metasploit, the logging should function independently of it.