Registry plugins spread across directories. Needs standardization

[atcuno]

We have a sub directory 'registry' under framework/plugins/windows that holds two registry related plugins.

We then have amcache (https://github.com/volatilityfoundation/volatility3/blob/develop/volatility3/framework/plugins/windows/amcache.py), cachedump (https://github.com/volatilityfoundation/volatility3/blob/develop/volatility3/framework/plugins/windows/cachedump.py), lsadump (https://github.com/volatilityfoundation/volatility3/blob/b1a42d9510046377a426d62f7cbde1ce1a4ad528/volatility3/framework/plugins/windows/lsadump.py), hashdump (

volatility3/volatility3/framework/plugins/windows/hashdump.py

Line 330 in b1a42d9

def get_hive_key(cls, hive: registry.RegistryHive, key: str):

), and maybe others which use the registry, outside the folder.

There are 20+ new and useful plugins that can be written that target the registry, and I was talking to some college students about them as an easy intro to learning the framework - but then I realized we have plugins in multiple places and need to standardize this before it gets worse and before parity.

@ikelos @superponible - I assume these should all be under registry? What needs to happen version wise when we move plugins? These plugins also triggered many bugs in mass testing so we need to get them moved rather quickly so the bugs can be then be patched also.

[ikelos]

Generally plugins that are specifically designed to act upon the registry, should live under the registry group (it was supposed to be an example of how we could categorize plugins, but then no one ever really did it with any of the other plugins). As to moving a plugin, I guess you leave a class that inherits under the old name, but with a deprecation warning? Then two or three releases later (after people are using the new one), we can ditch the old one. Since it's a new plugin, technically it can have its version bumped back to 1.0.0, but I might leave it at whatever it's at for simplicity? All core plugins should be updated to use the new one (not the deprecated one). Does that answer all the corner cases, or have I missed some?

[atcuno]

That sounds good. I was make sure the test cases are valid for the new ones.

As for the deprecation -- if the current file inherits from the new file under registry/, where would the deprecation warning go.?I assume we want it in run(), so would the existing file override run to be the same except adding the warning?

[ikelos]

Yeah, basically run would be:

def run(self, *args, **kwargs):
    warnings.warn(DeprecationWarning('This plugin is now called BLAH'))
    return super().run(*args, **kwargs)

[ikelos]

Actually, thinking about it, we probably want it under __getattr__ or something, so that class methods would get caught? warning.warn would ensure the warning's only issued once, but just so we get visibility over dependencies. We'd probably need to leave out get_requirements but otherwise...