[Release n.n] Project Management Milestone Checklist

The milestone checklist tracks the development tasks that need to be completed for releases.

Security

Background – The security of the FIO protocol against DDOS and man in the middle attacks is one of the primary security objectives of the prorftol. The FIO protocol also concerns itself with the many ways that users might attempt to game the provided interfaces in order to gain FIO or to impede the experience of other users.

Objective – The objective of the Security section is to guide the lead developer of each project within a release to perform any of the necessary security testing for a given project. If changes are simple in nature this section may be excluded.

Recommended tactics – Core team members, and other FIO community members may be enlisted to perform security reviews of the changes being proposed by a project. 3rd party security audits are also welcomed on all projects delivering into the FIO protocol. Please contact the release manager if you desire recommendations for 3rd party reviewers. When time and resources permit, there may also be consideration of placing the changes into either a private test instance of the FIO protocol (private test network), or placing the changes onto test net for an extended period of vetting by the community.

Deliverables – Findings for security audit, bounties, and vulnerability tests are sensitive materials and may be published to the public after careful consideration of the consequences of publishing this material. Once vulnerabilities have been adequately addressed all findings and remediations should be posted to the wiki for the project in question. provide a set of links to completed items, or provide a point of contact for your project if items are in work.

Code Audit – A security focused audit of contract modifications should be strongly considered for any new actions, or any modifications to actions that involve changes in authorizations, or error logic. Code audits can be performed by core team members, or they can be performed by third parties specializing in EOSIO security issues.

Vulnerability Testing – The project may benefit from security focused stress testing. This testing may be performed by core team members, or by contracted parties hired for the project. The testing might take an EOSIO specific focus, with the addition of penetration, fuzz, gaming the system, and other vulnerability testing is strongly advised.

Bug Bounty – Your project may benefit from placing a bounty on the contract modifications. Your project should consider offering a reward if any community member is able to discover security flaws, or vulnerabilities in new features. These bounties may be long lived, and they may require the use of private test instances of the fio test net to provide hackers ample opportunity to “break the chain”.

SDKs

Background – Changes to Kotlin, javascript, and Golang SDKs may be necessary for each release of the FIO protocol. SDK changes should go through a QA process. The release manager must integrate the SDK changes required for a release, then perform acceptance tests on these changes.

Objective – The objective is to provide integrators with the new features and functions which they will integrate. The release manager ensures that the necessary SDK changes have been rolled up, and that unit testing is successful on the resulting SDK release

Deliverables – The release manager will post testing results on the wiki for each SDK release to provide an audit trail demonstrating the acceptance testing performed on an SDK release.

Kotlin Tests – The release manager will run the unit tests on the release image of the Kotlin SDK and will post results to the wiki.

Typescript Tests – The release manager will run the unit tests on the release image of the typescript SDK and will post results on the wiki