Versioning: implement a way to restrict LinuxUtilities calls

[Abyss-W4tcher]

Hello,

Internal APIs do not currently version restrain calls to LinuxUtilities, as we already do when requiring modules or plugins in plugins requirements. The issue is that any changes to these APIs requires depedant functions to be updated as well, without automatic versioning checks like get_requirements().

If you are interested in planning a fix, please read the following discussion (which is where the issue arose) as it pinpoints problematics and challenges:

• New linux plugin: modxview #1330 (comment)

[ikelos]

I think that the LinuxUtilities class is versioned? It's just also very big, so I'd suggest splitting out clumps of functions into feature sets (like the tainting module). Initially we forward on the calls (after checking the version and throwing a deprecation warning if the version matches, or a major error if the version doesn't match) and eventually those functions will get removed completely (or just reduced to a flat error). That will allow us to make the change without having to bump the LinuxUtilities API, it'll produce deprecation warnings in any class calling it, but gives us time to fix it up before the final release. Does that sound workable?

[Abyss-W4tcher]

For me, the main issue here, is that we do not have a way to express those version requirements.

Plugins can express requirements, which are checked before the plugin is allowed to run. However, if there is an internal API (say a function inside socket class) that requires sub-LinuxUtility API, we cannot require a version currently. Plugins might not even be aware of this requirement.

[ikelos]

At the moment, they version check LinuxUtilities to make sure it's suitable. The point of splitting things out is to make the versioning more fine grained.

It's infeasible for internal components of volatility to version check other internal components of volatility. They should all be released in one cohesive working order at each version release (and ideally, without breaking commits in between, but that's slightly more acceptable), so the only reason to version check them is when an externally written plugin may try to access them (not when an internal one does, which the plugins do through their requirements). If we have to check every crosslink between internal components we'll spend all our time error checking and not actually getting any of the work done.

However, since LinuxUtilities contains several unrelated components, any change to one of them may invalidate all existing plugins that rely on it, whether they use that component or not, which is why we're splitting them out. Hopefully that makes sense?

[Abyss-W4tcher]

Sure, splitting utilities into smaller chunks is definitely something we should look into.

I was mostly concerned about the internal APIs cross-requirements, but as you said, it will be quite difficult to maintain. If it's not an absolute concern in the end, I think we can close this issue.

I opened it following this comment from you on the modxview PR, where an internal API was calling a split LinuxUtilities API:

Technically, that proxy call also needs to check that the Tainting module is the right version (although it would only prevent errors if the Tainting module MAJOR version went up and someone forgot to change this method.

[ikelos]

It's not, we can keep all of our components working with each other as long as we're careful. It's other people's code we can't look after and so we have to give them a way to tell whether it'll work or not...