128: Allow the user to cancel interactive mode

[adrianbn]

This should resolve #128. The change is so straight forward and any potential tests would be awkward, so I'm not sure we want to include specific tests for this (there were none before for interactive mode anyway).

I'm open to suggestions though.

You can manually test this change by using this sample code:

import scrypt


image_name = request.args.get('image_name')
if not image_name:
    image_name = 'foo'
foo = scrypt.outer(image_name) # Any call after ControlFlowNode caused the problem
foo = scrypt.hash(foo, 'salt')
foo = scrypt.encrypt(os.urandom(datalength), foo)
send_file(foo)

Then python -m pyt sample.py -m bb.txt -i. You can see how it does as many as you want until you answer s.

[KevinHock]

I don't think you need the interactive = False assignment because you're returning.

[KevinHock]

We could make it so that for other vulnerability chains as well, it doesn't ask for user input anymore. But I think this change is definitely good and a step in the right direction, I'm happy to merge :D

(fwiw I don't think my comment on the issue was very clear.)

[adrianbn]

That's a good point. I can make that change so that we stop it for all chains.

[adrianbn]

So the last commit stops asking for all chains, but I'm not 100% satisfied. There aren't many better options without touching too much (e.g. making an Interactive/Mode object, or a Config object and making interactive one of its elements). This is easy but inelegant.

I have not fixed Travis' complaints about too many returns inside that function. While that is true, refactoring this function isn't trivial so I'd like to get some input on what's the preferred path forward, both for Travis and the general solution.

[KevinHock]

I agree it's inelegant, but it's good code 👍

Maybe in the find_vulnerabilities def we can do something like

>>> class Interactive():  # Maybe in `vulnerability_helper.py`
...   def __init__(self):
...     self.on = False
...   def __bool__(self):
...     return self.on
... 
>>> interactive.on = interactive_mode  # Where we currently do `interactive = False`

Where we rename the interactive arg to interactive_mode in that function def. I'm happy with whatever you prefer though, as I'm as unsure as you are.

Code Climate complains about a lot of things in the existing code, I don't know if there's anything we can do in this case.

[KevinHock]

(Gonna go ahead and merge 👍 , if that's okay, as it's good as-is.)

[adrianbn]

Sorry, I'm having a hard time finding time lately due to some personal commitments. I was working on a nicer approach, but I'm happy to see this merged and we can improve it later.

[KevinHock]

No worries @adrianbn 👍 Same here.