boofuzz/sessions.py is too long and complicated, let's fix that. about boofuzz HOT 8 OPEN

@jtpereyda @MetinSAYGIN

So, it happens that I have some code lying around that has this done, more or less; but without the SessionOptions object. I'm still in the process of getting permission to opensource it, but it's 100% on me that it has been stale for this long.

However, my code depends on #638; and since I'm currently in the middle of moving houses I probably won't get around to finish that anytime soon. So if someone could pick up there, I can maybe allocate some time in the near future to get the other code in a PR.

Just a word of warning though; the particular way I chose to split the Session class was heavily influenced by my research needs. It might need some more work before being ready to merge and as it currently stands, I'm unsure whether I can allocate the time neccessary to do so. Originally, I planned to hire a student assistant to finish this PR and aid my research, but so far this hasn't come to fruition.

from boofuzz.

I'll also understand that this will probably create some merge conflicts with #624. At the moment though my goal is to move code, not to edit it, so these should be resolvable fairly easily.

from boofuzz.

On further consideration, it seems to me that many options will simply be unnecessary in the first place once the pipeline is dynamic and pluggable. Take for example this excerpt:

These options can simply be set when creating the step instance for the pipeline, and thus don't need to be set in the sessions constructor.

Obviously, boofuzz should make it easy to get some set of default pipelines with a subset of configuration options for common use cases (think from boofuzz.pipelines import default_pipeline).

from boofuzz.

I'll also understand that this will probably create some merge conflicts with #624. At the moment though my goal is to move code, not to edit it, so these should be resolvable fairly easily.

Right now there's no foreseeable date on when I'll get approval to release my contributions to the public. Regardless, I agree that the merge conflict that may rise from this will be easy to resolve.

from boofuzz.

Is this ticket still open ? I probably would like to contribute for it.
Metin

from boofuzz.

@mistressofjellyfish Thanks for the issue! My apologies as I've been way behind on open source work.

I like the overall idea. 100% agree on splitting out classes.

I would say that my bias is heavily toward backwards-compatibility for imports. It's easy to use aliases to preserve importable names, so it won't create a huge code overhead.

I'd lean the same way with regard to SessionOptions. Keep the kwargs and use them to create a SessionOptions within the Session constructor. You can use a helper method if it helps readability in Session. I actually think the Session constructor, though long, is relatively easily understood.

Re fuzzing loop -- I definitely agree there is room for improvement, though I'm not entirely sure how. The code used to be more procedural, and I refactored it to be a little less stateful. The logic is confusing, but a key attribute is that it enables multiple mutations on one message. That's a property I would want it to keep. For starters, just moving this logic outside Session might be a good step.

I'll check out the PR too.

from boofuzz.

@MetinSAYGIN #638 has some minor changes requested that somebody could take over! Feel free to build on that PR and fix the minor issues.

from boofuzz.

@mistressofjellyfish thanks for the update -- if you get it approved, an in-progress PR is plenty welcome. Good luck!

from boofuzz.