RFC: Module Deprecation/Removal policy update

[jmartin-tech]

Problem

Metasploit modules that have little to no remaining install base are still packaged, loaded, and searched for by all installations. This creates both an inaccurate view of how many usable modules exist in Metasploit and increases the burden on development to maintain and support for code that is no longer viable.

By maintaining modules in perpetuity development practices have to support or update the code for these modules that may not even be viable in test environments.

Potential solutions

Define a documented process for modules to age-out of Metasploit Framework.
What might this look like?

• 5 year maintenance window for all modules base on last enhancement to the module.
  This would allow for modules that see updates for newer supported targets often to live longer by default.
• An exemption list for modules that have reached the end-of-maintenance value yet are known to still have consistent targets or usage.
• Removal of modules on a quarterly basis with update to exemptions.
• Community input on exemptions can be provided in the removal PR each quarter, possibly with announcements via blog, twitter or both.
• Issues opened with a legacy retain label could also offer community input on modules that should be retained out of cycle.

[adfoster-r7]

Potentially we could create module "placeholders", so the metadata still exists in Metasploit. This could also impact the JSON metadata file. That would mean you can still search for the module and view its info - but if you try to use it, we can notify the user that it's been removed - and provide a link to somewhere that we can keep track of the details - perhaps a simple Google form so we can aggregate the information easily.

[jmartin-tech]

One of the points a removal policy is intended to make is, modules have a lifespan of relevance. Currently the signal to noise on relevance is getting out of balance. Keeping metadata for search support may reduce the value of removal.

[adfoster-r7]

It feels as though there needs to be an intuitive way to educate users why modules are no longer present, particularly if users are following old tutorial/books/training labs. We've noticed issues in the past with users being confused about not being able to find consolidated modules etc, keeping the older modules still searchable - but highlighting to the user that it's been removed would help alleviate that pain. It would also tick the box of no longer having maintenance burden of the module itself.

[jmartin-tech]

This concern is valid, and has been a factor in the current deadlock on removal that exists today. There needs to be a better reason to keep things around than a tutorial/books/training lab in the last 15 years referenced it.

I could see a possible compromise of having secondary cache of names for removed modules that simply triggers a canned message stating the module is no longer available as of a specific version, however I would suggest this should only be triggered by an attempt to use. The search results should not be cluttered with these deprecated results.

[bcoles]

I'd like to see an "official" exploit pack made available for "legacy" exploits. If the metasploit project and rapid7 has no interest in maintaining these modules then perhaps members of the community can maintain these modules in a separate repository.

Granted, this still incurs overhead for the project to verify pull request changes to the legacy repo. I presume there will be little interest from the team to manage the repo and I don't see value in bringing new members on board solely for this purpose. As such, modules should be made available "as is" with no guarantees of support or maintenance.

This way at least the modules won't be discarded entirely and there is possibility of maintenance in a manner more suitable than other repositories which do not support maintenance, such as Exploit DB.

[jmartin-tech]

An interesting take, I see some possible value in having a legacy location. One possible route to look at would be, simply move legacy modules into another location in tree that is not loaded by default. This idea could model after the test modules that sometimes provide usage or functionality test or examples.

Since the project is a public repository on the other hand, a module is never truly discarded making a reference to the last version the module existed in a source for the obtaining the module.

[timwr]

I suspect having a legacy directory might be the simplest solution, users can still easily load them with msf6 > loadpath legacy, and we can retain the module history.