Difference between revisions of "Release Meeting Minutes/2009-06-16"
From K5Wiki
(New page: 1.8 release: * Feature freeze around January 1 * Delivery around March 1 * Testing of new features as they are added * Documentation of hand-testing procedures which are hard to automate (...) |
m |
||
| Line 21: | Line 21: | ||
** We proposed new enctypes using SHA2 hash algorithms |
** We proposed new enctypes using SHA2 hash algorithms |
||
** We got some pushback from people wanting to minimize the number of Kerberos enctypes |
** We got some pushback from people wanting to minimize the number of Kerberos enctypes |
||
| − | ** NIST's statement does not require agencies to stop using SHA1 for HMACs or PRNGs on any fixed |
+ | ** NIST's statement does not require agencies to stop using SHA1 for HMACs or PRNGs on any fixed date (only for uses requiring collision resistance) but does encourage the use of SHA2 |
Revision as of 13:55, 21 June 2009
1.8 release:
- Feature freeze around January 1
- Delivery around March 1
- Testing of new features as they are added
- Documentation of hand-testing procedures which are hard to automate (perhaps a wiki page for this kind of documentation)
- Hand-testing procedures can be useful even if an automated test exists (because they are simpler)
- Zhana proposed a testing milestone halfway through the development cycle, where we verify that we can test every new feature developed so far
- Will notes that developers don't always write the best tests for the code they wrote; it's valuable to get input from other developers on what tests might be useful
- Should think about how to decrease the barrier between "having a written manual test plan" and "adding to our automated test suite"; currently the barrier is too high for many developers
- (Some discussion of the limitations of our testing infrastructure)
- (Some discussion of performance testing)
- Feature freeze is a good time to look for performance regressions
- We have some reported performance issues we should look into for 1.8, independently of that
- Crypto modularity
- Some possible back ends (like PKCS11) require opaque handles, and also support keys being withheld from the application code
- Another issue is fork safety (PKCS11 handles should not be used across forks)
- Supporting these requires API changes
- Sun's solution was to add a derived key list, pid, and PKCS11 object handle to the keyblock
- Sam's proposal was to create a special kind of key where the key data is a handle to an extended object (breaks application code which makes its own use of the keyblock data)
- SHA2
- We proposed new enctypes using SHA2 hash algorithms
- We got some pushback from people wanting to minimize the number of Kerberos enctypes
- NIST's statement does not require agencies to stop using SHA1 for HMACs or PRNGs on any fixed date (only for uses requiring collision resistance) but does encourage the use of SHA2
