HANDLING RESULTS
Last updated
Last updated
6.4.1 REVIEWING A FIX
Once you have filtered for the set of fixes for review, you may begin processing them. That typically begins with clicking on the Unresolved tab to see what fixes need to be reviewed. In our example, we will be looking at a set of fixes within the Sensitive Data Exposure category. There were 7 fixes identified. To show how to process a fix, we will look at Fix SDE-PyRRG-1-1.
In this example, it has detected the use of a weak encryption library leading to possible attacks. To learn more about this issue, you can click on the link should not be used for security purposes to learn more about the use of pseudo-random generators.
To strengthen the security for this issue, it is recommended that the weak random library be replaced with the stronger secrets library.
To see the diffs for this fix, click on the Show Diff button. Doing that reveals an expanded display.
There is a Diff: tab shown where the tab displays the changes suggested for the affected file. In this example, Diff: 1 is selected and displayed. This is the diff for the file using the weak library.
The lines that were changed are identified by the red highlighted statements. In this example, those are Lines 1 and 32. The text below that shows the corrected code with green highlights. The iCR generated code corrects the issue by replacing the import of the random library with the stronger secrets one. In addition, the usage statement 32 is updated to refer to the stronger pseudo-random number generator secrets.SystemRandom.
If you want to browse the original source file associated with this fix, you can click on the Show Source button. A scrollable window will appear below the diff window with tabs for each of the files that have a diff for this fix. You can click on any tab to browse the source for any of the affected files. In this case Source of Diff: 1.
You can scroll through the original source file independently of the diff window.
Once you are satisfied with reviewing a particular correction, you can select other Diff: tabs to review all the suggested changes for this fix.
To view other fixes, scroll through the list of fixes or select new filters.
6.4.2 ACCEPTING A FIX
Continuing with the example of Fix SDE-PyRRG-1-1, there are 2 buttons at the bottom left of the diff window. They are labeled Accept and Reject. These options allow you to make a decision on whether or not the changes are desired.
By clicking the Accept button, the fix (SDE-PyRRG-1-1) is placed in the Accepted state. If this had been a fix involving multiple diffs, because the change required updates to more than one file, all of the changes are connected and changing some without the others would result in invalid code. It does not really matter which particular diff is used to accept or reject the changes.
Note that the summary tab now shows one fix in the Accepted state. Its tab is now highlighted in Blue because it is no longer empty.
Clicking on the Accepted tab brings up the list of accepted fixes. In this example, there is the fix we just accepted, fix SDE-PyRRG-1-1.
6.4.3 REJECTING A FIX
It may be that there is a reason for not accepting a fix. If so, you may choose to click on the Reject button. This behaves in exactly the same way as accepting a fix. All of the diffs associated with this fix are kept together and the fix moves to the Rejected state. For an example of this, we will reject fix SDE-PyRRG-1-2. After clicking the Reject button, the fix is moved to the Rejected state and that is reflected in the summary tab.
Clicking on it reveals the rejected fix:
6.4.4 UNDOING A FIX
Using the above example of SDE-PyRRG-1-2, it may be realized that the fix is, indeed, needed, and that you want to change its status.
Clicking on the Show Diff button, as before, will display the original code and the rejected changes. But you will notice that the buttons at the bottom of the window are different from the Unresolved fixes with a new button at the bottom.
A new Undo button is now available. If it is chosen, then the fix moves back to the Unresolved state where it can be left for further review later.
Since this example is one of a rejected fix, then the other option, to accept it instead, is also offered. So, you can click on the Accept button, and the fix will be moved from Rejected to Accepted.
A similar process works for accepted fixes. Should the user decide to reject it instead, the Reject button is available. Also, as in the example above, the Undo button is also there as so the fix may be moved back to the Unresolved state for later review.
A fix can be moved from any one of Accepted, Rejected and Unresolved states by clicking the appropriate button while displaying a diff.
6.4.5 REJECTED FIX HISTORY
Rejecting a bug indicates that, while an issue has been detected, the decision was made to not apply this fix. So, what happens to such bugs once a review of a session completes? iCR for Python maintains a history of the rejected bugs so that they do not need to be processed in subsequent analyses.
For the previous examples, we had been working on the second of 2 analyses. In the first analysis review, we rejected a bug in order to show how the history works.
Looking back to the Show Details for Session 2 which we showed earlier, we see that the Rejected tab already has a fix in it. It is the one that was rejected from the first analysis. All rejected bugs from previous analyses are tracked and will always show in the Rejected tab. Clicking on it shows a rejected bug from the earlier analysis session.
Bugs that have been previously rejected have their severity icon greyed out. This tells you that this rejection comes from some earlier analysis. Previously rejected bugs are always displayed following any newly rejected bugs. In the example below, you can see that newly rejected bug SDE-PyRRG-1-2 has the expected severity color while the previously rejected bug In-PyFT-18-2 is greyed out.
Rejected bugs are kept in the Rejected tab until they are eliminated from the code. Keeping them in the history allows you to change your mind in the future should you decide otherwise and choose to accept the bug later on. Also, the highest severity previously rejected bugs always follow the lowest severity newly rejected bugs.
6.4.6 PROVIDING FEEDBACK
When looking at diffs that are in the Unresolved state, you will note that there is another option shown on the bottom right of the diff window opposite the Accept and Reject buttons.
This is a pull-down menu that offers your developers the opportunity to provide feedback to OpenRefactory engineers.
While iCR for Python has a comprehensive analysis engine, there are always ways to improve it. Should your engineers determine that there may be an error in the analysis, or some other issue that they would like to see improved, they can select one of the feedback options and write a brief email for our development team.
The feedback window gives your developers the options to include the text of the fix and source code snippets so that we can evaluate our analysis and our correction.
We are constantly finding ways to improve both our analysis and the quality of our fixes, so your feedback would be welcome.
6.4.7 APPLYING THE FIXES
The Reviewer provides the ability for you to select, browse and identify fixes to be accepted or rejected. The main purpose of this process is to be able to apply these fixes to the source code itself.
When reviewing fixes in the Accepted state, you may click on the Show Diff button to review the offered changes. The display is a bit different from the one shown earlier.
Since this is an Accepted fix, the options at the bottom of the window are different. The Undo button is there as before, but now the user has the option of changing their mind and rejecting the change. That will move it over to the Rejected state.
It may be the case, especially if you are executing iCR for Python for the first time, that there will be many offered fixes to be reviewed. You may want to distribute the task of reviewing the fixes to multiple members of your team. Or, you may want to review fixes in batches over time. You can end a Reviewing session at any time by clicking on the Home button. This will redirect your tab back to the Navigator. This is handy if you had closed the Navigator tab from before. Or you can simply close the Reviewer tab and return to your previous Navigator tab. In either case, your Reviewer session ends.
The Reviewer also monitors your activity. If you are idle for a period of 15 minutes, the reviewer pops up an alert asking if you want to continue the session. If so, simply click continue to proceed.
If you allow the timeout to expire, your Reviewer session will end, and a simple display will be shown to let you know that iCR for Python ended your session.
Of course, you can always end your session by simply clicking the Exit iCR button.
