-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixing "Error handling difficult and not reliable #38" #39
Conversation
- Run() does now return a result, optional warnings and an error if something critical went wrong. The error might come from the package or Nmap - Issues from Nmap's stderr are all treated as warnings. If something critical went wrong, it can be found in the Nmap result XML (and will also be read from there raising an error) - All currently experienced Nmap errors are added as error constants in errors.go. People can use these error constants to handle individual errors individually. This should be extended as more new errors are found - Removed 'NmapErrors' from xml.go again, as this was only required with the previous Nmap result error fix
moved to utils.go
examples were missed
In a previous version duplicate messages from Nmap stderr got removed. As we understand these messages as warnings now, I think it's not good to alter/clean these messages anymore, in order to give full control to the developer. The developer still could do a "unique" on the returned list of messages on his own. In other cases he might want to know how often a certain warning happened, etc...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you very much for this contribution @noneymous! This is great.
Looks solid so far! I have a suggestion that impacts a few little things, and also it will require unit tests before it can be merged. I didn't test it yet but I will as soon as I have some time 🙏
Good idea, I introduced named return values and it's already commited. Just the warning unit test outstanding. Maybe tomorrow. |
Sorry, I'm in the wrong environment to get the tests running. I feel this would take me too much time but might be a simple thing for you... |
Awaiting Unit Tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks promising and well laid out. I agree, we need unit tests as this is a pretty big change across many files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me
Thank you guys |
What's the plan, when do you intend to merge? |
@noneymous we will merge once tests have been completed. We thank you for your patience. Both myself and @Ullaakut have busy schedules at times. |
I'll wait for @TheSecEng to test it as well and once it's fine for him, we can merge the PR :) |
Cleared. |
Here comes the implementation of my suggestion to fix #38. Please have a look and see how this works for you. I tested it against some scan targets and am still running it against even more. You are probably using different Nmap arguments than me, so I'm curious about your experiences.
Result processing would be like:
OptionB: Ignore warnings at all and just work with the returned XML. It already contains a lot of details
Here is sample usage code: