soc-se-bot
commented
1 year ago Team's Response
The dev acknowledges that there is indeed an issue with the functioning of the program with corrupted (tampered) data file. However, the dev team believes this is not in scope "as rectifying it is less important than the work that has been done already". Furthermore, as seen in the screenshot below, the UG clearly indicates that it is out of the scope of the product to fully function with illegally tampered files. Users should not be editing the data file in the first place. Data corruption protocol only seeks to be a safety net for unexpected corruption such as during crashes.This is further emphasised in the DG (second screenshot).
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: Screenshotting the full excerpt from the DG, this scenario falls under case 1, since the data needed for the API call (module code) is not tampered with. The DG states that there is no impact on the start up of the program and that the simple functionality (such as searching for details of a module, that do not involve the timetable) should still work.
Naturally, the team would not be expected to handle the data recovery by filling in the missing fields, but should still be expected to handle the tampering by minimally purging the data file or purging problematic lines.
As written in the user guide, the user is not expected to tamper with the data files (hence severity low). However, the system should still be able to recover from it e.g. by starting fresh. Instead, the system is rendered unusable.