| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Rename all affected files, references to file paths, and module imports
within the code. Since this line of development represents a fork from
the original sploit, a name change is seen as necessary to distinguish
the projects, as well as allow them to be installed side by side.
What does the "n" mean? Great question! You can think of it as meaning
"new sploit" if you want, though that's not quite intended. The name is
simply distinct and easy to pronounce. I had originally settled on
"msploit" (something along the lines of "Malf's sploit"), but this name
is too close to "metasploit" for me - and N is right next to it on the
keyboard.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
We would like to move additional modules under the namespace of "util"
to clean up the top-level "sploit" package. To start, the functions
from the previous util module are moved. Given the package is named
"util" the module is renamed to "cmd" to somewhat match the theme of the
contained functions.
Per the previous commits, these functions are now exposed via the util
package as well.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Instead of hard-coding the version into the pyproject.toml, we can
dynamically source it at build time. Ideally, we want to use git
describe as a single authority source on the version. The version is
stored in sploit.__version__ and can be consumed during sploit runtime
or during a build/package to populate the project's core metadata
version in the toml file.
hatchling provides a tool.hatch.version plugin that can read out the
variable during a build/package. Because this variable is populated
from a git command, if the source tree isn't in a git repo, it will
fail. In this case, sploit will report a PEP 440 compliant fake version
"0+unknown.version" to let the user know.
Because a packaged distribution doesn't exist in a git repo, we want to
bake in the version at build time into the package. hatchling provides
a plugin to help with this, but it had some technical limitations that
didn't quite work for our use case. Instead, I added a custom build
hook which will take the version sourced from the package (and by proxy
the git command), and overwrite the __init__.py with a hard-coded
version in the __version__ variable. This means that built/packaged
distributions of this project will have a fixed version hard-coded in
rather than dynamically sourcing from git.
The build hook operates just before the build executes. It seems that
most build/packager front-ends (e.g. build, pip) will just run it in the
current source tree rather than making a temp copy. This means that
when we modify the __init__.py, it is modifying our git tree. Ideally,
we want this to be restored at the end of the build. The build hook
interface allows us to write a hook that happens after the build, but it
won't run in the case of a crash or failed build. Instead, I added a
custom solution to this using a member variable deconstructor. If the
build ends in any way, the original contents of __init__.py are written
back out.
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
Reviewed-by: Malfurious <m@lfurio.us>
|
|
__getattribute__ is the low-level magic func and will intercept every
attribute lookup, whereas __getattr__ is high-level, and is only invoked
in specific conditions (such as __getattribute__'s failure).
As such, any overload of __getattribute__ which preferentially falls
back to object.__getattribute__() before serving a request, can more
simply be replaced by a __getattr__ overload without the fallback.
Signed-off-by: Malfurious <m@lfurio.us>
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Found a spot to use __attr_filter__ in the rev module, so moving it out
of mem and into a shared place (util).
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
rather than cacheing ELF instantiations, just cache the results of
external commands
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
