Merge branch 'main' into feature/installed-module-packages

Route loaded module logging under the mvt.ext namespace
Modules loaded from installed packages or file paths live outside the mvt logger hierarchy, so their log records never reach MVT's console and file handlers and instead fall through to logging.lastResort: alerts print as bare unformatted lines and INFO messages are dropped entirely. Add get_module_logger() and use it everywhere module loggers are created. Built-in mvt.* modules keep their existing logger names, and everything external is parented under a dedicated mvt.ext namespace so records reach the handlers and external names can never collide with MVT's internal logger tree. File-path modules are named after their file (mvt.ext.<stem>) instead of the mangled internal import name. Document a naming convention for community module packages: distribute as mvt-plugin-<name> with import package mvt_plugin_<name>, including the publishing organization in the name. The prefix is advisory (loading is by entry point, and it is no mark of authenticity), but conforming packages get a cleaner logger namespace: the mvt_plugin_ prefix is stripped, so mvt_plugin_amnesty_custom logs as mvt.ext.amnesty_custom.
2026-10-27 16:26:23 +01:00 · 2026-08-19 23:13:58 +02:00 · 2026-08-19 22:53:09 +02:00 · 2026-08-19 21:30:07 +02:00 · 2026-08-19 14:03:09 +02:00
4 changed files with 4 additions and 4 deletions
@@ -84,7 +84,7 @@ details.

 Users can also add top-level commands to `mvt-ios` and `mvt-android` from
 installed Python packages or local files and folders. See the
-[custom CLI command documentation](https://docs.mvt.re/en/latest/development/custom_commands/)
+[custom CLI command documentation](https://docs.mvt.re/en/latest/custom_commands/)
 for the plugin entry points and `--load-command` interface.


@@ -1,7 +1,7 @@
 # Custom CLI Commands

 MVT can load additional top-level commands into `mvt-ios` and `mvt-android`.
-Custom commands are different from [custom forensic modules](index.md#custom-modules):
+Custom commands are different from [custom forensic modules](development.md#custom-modules):
 commands add new CLI operations, while modules add analysis steps to existing
 `check-*` commands.

@@ -50,6 +50,6 @@ nav:
        - Check Android Intrusion Logs: "android/intrusion_logs.md"
    - Indicators of Compromise: "iocs.md"
    - Development:
-        - Development Instructions: "development/index.md"
-        - Custom CLI Commands: "development/custom_commands.md"
+        - Development Instructions: "development.md"
+        - Custom CLI Commands: "custom_commands.md"
    - License: "license.md"
Author	SHA1	Message	Date
Donncha Ó Cearbhaill	31f3937bfd	Merge branch 'main' into feature/installed-module-packages	2026-08-19 23:13:58 +02:00
Donncha Ó Cearbhaill	8eefcb706a	Route loaded module logging under the mvt.ext namespace Modules loaded from installed packages or file paths live outside the mvt logger hierarchy, so their log records never reach MVT's console and file handlers and instead fall through to logging.lastResort: alerts print as bare unformatted lines and INFO messages are dropped entirely. Add get_module_logger() and use it everywhere module loggers are created. Built-in mvt.* modules keep their existing logger names, and everything external is parented under a dedicated mvt.ext namespace so records reach the handlers and external names can never collide with MVT's internal logger tree. File-path modules are named after their file (mvt.ext.<stem>) instead of the mangled internal import name. Document a naming convention for community module packages: distribute as mvt-plugin-<name> with import package mvt_plugin_<name>, including the publishing organization in the name. The prefix is advisory (loading is by entry point, and it is no mark of authenticity), but conforming packages get a cleaner logger namespace: the mvt_plugin_ prefix is stripped, so mvt_plugin_amnesty_custom logs as mvt.ext.amnesty_custom.	2026-08-19 22:53:09 +02:00
Donncha Ó Cearbhaill	e77008b49a	Record the source of loaded modules for auditability Now that installed module packages load automatically, record where every module came from: - --list-modules groups the available modules by source, one line per source with the modules comma-separated: MVT itself with its version, each installed package with its version and VCS commit when recorded (PEP 610 direct_url.json), and each --load-module/MVT_CUSTOM_MODULES file with its SHA-256 hash. - Commands log one line per module source with its version or hash and the modules loaded from it, so command.log records exactly which modules ran and where they came from. - Make init_logging() idempotent: a loaded module package importing an MVT CLI module would previously add a second console handler and duplicate every console log line.	2026-08-19 21:30:07 +02:00
Donncha Ó Cearbhaill	cb25137423	Load installed module packages via entry points Python packages can already register custom CLI commands which load automatically, but custom modules still require --load-module or the MVT_CUSTOM_MODULES environment variable on every invocation. Add an mvt.modules entry-point group so installed packages can register forensic modules which load automatically into every module-running check-* command. An entry point resolves to an iterable of MVTModule subclasses, or a callable returning one. Broken entry points are skipped with a warning so a faulty package cannot break MVT.	2026-08-19 14:03:09 +02:00