Open mattsb42-aws opened 4 years ago
The plan I've arrived at for this is:
The overall picture for a specification change flowing through all the affected projects will look like this:
Some specification changes will not need any actual test vector or implementation changes (for example, when a squishy human makes a spec change just to enter “Y implementation now meets specification feature X version 1.1"), in which case steps 3 and 5 will just be approving and merging the Dependabot-created PRs. This shouldn't be a huge pain since Dependabot will continuously update the PRs it cuts to point to the latest version, so these updates can be easily handled in batches.
The test vectors will need to be expanded to cover more kinds of tests, but this flow will still help track the required tasks even when the specification change is not unit-testable, and we can apply the fully-manual approach while the test vectors catch up.
Am I correctly reading an implied "the spec repo and test vectors repo need to start publishing release tags"? If not, what commitish will the submodules point to and how will dependabot track/update that change?
No need for release tags - the submodules will just point to literal commit hashes for the current state, and dependabot should be triggered on every new commit to master. I'm experimenting with that now to confirm, however.
We need to find some way to check that an implementation complies with the specification.
One tool in this might be expanding the test vector framework[1] and test vectors.
Each specification document SHOULD be involved in these checks.
[1] https://github.com/awslabs/aws-crypto-tools-test-vector-framework [2] https://github.com/awslabs/aws-encryption-sdk-test-vectors