Removing explicit dependency on sslyze

[jsf9k]

If you liked #223 then you'll love this one!

[konklone]

@jsf9k I do love this one! But while we're doing this, do you have any suggestions on how to appropriately onboard users?

We can add docs for each scanner saying what to do before using them, or we could add requirements-pshtt.txt that could be used by new folks, and ignored as appropriate for users who are taking dependencies into their own hands.

There is sort of an implied contract between the scanner and the tool they use, though - the pshtt scanner is written for a certain minimum version/commit of pshtt, and that version goes up sometimes. Handling that programmatically in some way is friendly to users of the tool, and inventing a new dependency management system seems unwise.

What would be the ideal, for your workflow at least, and perhaps for others?

[jsf9k]

For my workflow I greatly prefer handling the scanner dependencies myself depending on what scanner(s) I'm using. I definitely see what you're saying about new users, though.

What about a requirements-scanners.txt file that pulls in all the scanners and some updated language in the README? Do you think that would be enough for new users?

[konklone]

I took this a little further and split out requirements into:

• requirements-gatherers.txt for gatherer-specific reqs,
• requirements-scanners.txt for scanner-specific reqs,
• requirements-dev.txt for requirements only needed for developing/testing domain-scan, and
• lambda/requirements-lambda.txt for only the requirements needed during Lambda invocation. (This is a subset of what's in requirements.txt, which is documented inside there.)

So now requirements.txt has just 3 things in it, and the Lambda version of it has 2. This should lighten function invocations, and more cleanly separate and document what's needed for each thing. This also makes it easier for folks to use their own dependency management for connecting domain-scan to their own environment-specific use of scanners.

[jsf9k]

This is good. I thought of separating out the gather requirements too, but I wasn't sure if that was something we wanted to do. I'm glad that it is 😃

[jsf9k]

Note that we'll want to replicate this splitting in the setup.py file that @IanLee1521 is working on in #231, probably by adding more sections to extras_require.