| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Since renaming the file to "README" (no file extension), the build
backend can no longer automatically determine the file content type, so
specify text/plain in pyproject.toml.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Ditch the txt extension...
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
The version information for the nsploit distribution is now defined in
pyproject.toml, and we no longer attempt to obtain details via
git-describe. As previously, the library version is made available via
`nsploit.__version__`.
The main benefit of working this way is to allow a proper install of
nsploit from a simple tarball of the source code, or even a shallow git
clone. In each of these cases, tag information will not usually be
present.
As an added feature over the previous system, nsploit will now report in
its version string if the running version is from a source tree, rather
than an installed copy.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
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>
|
|
The CLI logic is moved to sploit/__main__.py. This file is now the
target of:
- python -m sploit
- sploit.py (via import)
- sploit (installed executable - via pyproject.toml)
A module guard (`if __name__ == "__main__"`) is added to allow the
application to run when this file is invoked directly. And the
entrypoint symlink is no longer necessary.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
This dataclass is intended to be used directly with the new ROP builder
class. GadHints allow users to teach the library about gadgets it can
not find on its own and how to use them correctly.
Signed-off-by: Malfurious <m@lfurio.us>
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
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>
|
|
Currently, the standard way to build and package a Python project is
through a pyproject.toml file rather than the old setup.py. This is
also build back-end agnostic and we can choose to use something other
than setuptools. After looking through a few options, I've decided to
use hatchling.
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
Reviewed-by: Malfurious <m@lfurio.us>
|
