Administrative/Security Review
This is an administrative code review.
For the reviewer
@zcloutet will be performing the administrative/security review
All software must have an administrative security review before it is made publicly available by any method. This type of review ensures personal, private, or otherwise sensitive information is not included in the repository. Types of sensitive information include:
- Personally identifiable information (PII)
- Absolute file system paths
- Internal server host names or IP addresses
- Usernames/passwords
Administrative security reviews may be performed by any trusted person; the reviewer does not necessarily need a strong scientific or programming background. When migrating an existing project into any non-private Git repository, it is important to remember that the entire project history needs to be reviewed if that history is to be maintained after migration.
- The review should consider the entire commit history
- If development workflow included incremental peer reviews, this step is already complete
-
NOTE: At the time of this review the project has included incremental peer reviews so the project history has already been inspected
-
- If development workflow included incremental peer reviews, this step is already complete
- May be facilitated/reconciled via GitLab issues and merge requests against the release-candidate branch.
- An MR has been created to make viewing changes easier. This MR should not be merged until all reviews (code, domain, admin/security) have been completed and the code is ready for release. Merge request !132
- The reviewer can show that they are satisfied by closing this issue
https://www.usgs.gov/products/software/software-management/types-software-review
For the developer
@hhunsinger will be the developer point of contact for this review
- All changes made to address the reviewers comments should be made to the release-candidate branch
- Responses to reviewer comments can include:
- Making changes to the code
- Creating an issue to address the issue at a later time
- Explaining why changes will not be made
NOTE: for options 2 & 3 the reviewer and developer should agree to a reasonable resolution that does not compromise code standards
Process
The review process should be as follows:
- Reviewer reviews the code
- Reviewer adds comments to the issue outlining changes that need to be addressed
- Developer addresses each comment either with code changes (to the release-candidate branch), issues, or providing clarifying information to the reviewer
- Steps 1-3 are repeated until the reviewer is satisfied
- Reviewer comments and closes the issue
All reviews will be pointed at the release-candidate branch, so please do not merge that.