Context.object accepts a template or a string name (and now a type
flag). Module.object only accepts a string (because a template already
has most of the stuff built in and might as well be passed to the
Context.object constructor).
The gotcha here is the absolute flag, which must now be set
appropriately in all cases *except* where the module is constructed
with an offset of 0 (whereby it will have no impact).
This removes the assertions that checked plugin devs didn't do anything
overly bad in favour of using mypy to ensure appropriate type-checking.
It also moves the ProgressCallback typing information to constants in
order to avoid circular imports (since constants doesn't import
anything).
Originally we found physical offsets for pdbs that matched,
then found potential offsets and tested them against each other.
Now, we find the potential offsets and then look for pdbs at that offset
(technically within a 4Mb block after the start). The scanning is quick
(probably quicker than scanning the whole physical space) and should
catch most pdbs unless they're splayed out in virtual memory.
Since we stack using Mac layers as well as Linux layers, both sets of
banner caches are required. As the cache builders are separate at the
moment, we previously ran banner searches without any banners. This was
bad. It inflated memory hugely and killed the buildbot.
We now bomb out on stacking a Linux or Mac layer unless we have banners
against which to match.
In the dim and distant past, I seemingly thought it a good idea to copy
all the values out of an object's config and into local private
attributes (I guess to avoid config lookups?). It turns out, it was
always broken because it looking at the root of the config tree, rather
than under the object's specific config settings.
This first turned up as an issue where self._meta_layer was being
overwritten by None in the vmware layer. Removing this resolved the
issue.