Quality Assurance
Created by: anonimal
Note: this ticket has been replaced with #323 and the following:
&anonimal | down the road when we get closer to release, open tickets designed for a full QA review of particular components
&anonimal | rather than continue to tally sporadic areas as we progress.
&anonimal | So, if we ever coordinate a release date, 3-6 months before hand, *poof* open the ticket and follow QA model tooth and nail.
=======================================
Quality Assurance
Note: contributions/patches/new features are welcomed at any time during the cycle. Once this cycle has more experience, we should move it into our contributing guidelines.
Note: this cycle is currently under development; check back semi-often. All input is welcomed.
Phase 1: Basic Review
- All code must adhere to our guidelines in CONTRIBUTING.md.
- Refactor as needed according to guidelines
- Note areas that need improving (mentally or in code)
- Note/create TODO's and assign if possible
1st iteration
src/api
| 16f808d1 b7c8f464 // Completed
src/client
| 0c583add 16f808d1 b7c8f464 a2a003bb 2b81274a // Completed
src/core
| b7c8f464 1fdccd96 99dfaeac 90b38bc8 956ca961 ce8bc7d9 0488e7f2 // Completed
src/tests
| 0488e7f2 // Completed
2nd iteration
TODO // Only after a completed cycle or if necessary
Phase 2: Spec Comparison / Code documentation
- Doxygen support
- Complete spec review and comparison on a per module basis; e.g., Streaming, I2PControl, etc.
- Refactor/implement/patch when/where needed
- The code must be in-line with essential parts of the specification that maintain the same level of anonymity that java i2p provides.
- Document code as much as possible
- Code should be understood from novice to experienced coders
- Code should guide the reader to an understanding of I2P. I2P is very complex so our code should act as sovereign replacement of current documentation and not simply as a supplement. This can be a tedious objective but very rewarding in terms of maintenance and software lifespan.
- If satisfied, proceed with next phase, else repeat this phase or start from a previous phase..
1st iteration
API
- Datagram | // TODO
- I2PControl | 3d47e525 // In Progress
- I2PTunnel | // TODO
- Streaming | // TODO
Client
- Addressbook // TODO
- Destination // TODO
Core
- Crypto | // TODO
- Transport | 1dcbe27b #123 #165 #187 // In Progress
- Tunnel | a2a003bb 9dd3dc03 // In Progress
- Garlic | 82650a25
- I2NP | 6df2efda #125 // In Progress
- Identity | // TODO
- Leaseset | // TODO
- NetDB | // TODO
- Profiling | // TODO
- Reseed | #162
Phase 3: Implementation / Crypto Review
- An extension of phase 2: review that implementations are properly implemented
- Resolve all related TODO's
21:49:09 zzz | the moral of the story is, you need both timestamps and bloom filters to catch dups, no use having one without the other, and they have to have overlapping thresholds
- Make sure crypto is up to date and properly implemented
- If satisfied, proceed with next phase, else repeat this phase or start from a previous phase.
1st iteration
TODO
Phase 4: Security auditing
- Establish every vector for known exploitation
- Keep these vectors in mind when writing tests
- Break Kovri every which-way possible and then patch it up
- Use libraries when possible
2016-01-07 17:42:57 zzz anonimal, , while you are reviewing the code for buffer overflows - another pitfall is 4-byte length fields in several protocols. Any place there's a 4-byte length, be sure there's a bounds check to protect against OOM DoS
- If satisfied, proceed with next phase, else repeat this phase or start from a previous phase.
1st iteration
TODO
Phase 5: Bug squashing
- Resolve priority bugs/issues
- If satisfied, proceed with next phase, else repeat this phase or start from a previous phase.
1st iteration
TODO
Phase 6: Tests / Profiling
- Establish testing framework.
- Write tests for every api/client/core module.
- Run tests. Run them again.
- Full review of test results. Patch if needed. Refactor as necessary.
- Run valgrind. Patch if needed. Refactor as necessary.
- If satisfied, proceed with next phase, else repeat this phase or start from a previous phase.
1st iteration
TODO
Phase 7: Confer
- Confer with colleagues and the community
- Accept all feedback and, in response, produce tangible results
- Conferring should be done publicly via ticket, meetings, and/or on Irc2P/Freenode:
#kovri-dev
- If satisfied, proceed with next phase, else repeat this phase or start from a previous phase.
1st iteration
TODO
Phase 8: Repeat the cycle, start from the beginning
1st iteration
TODO