Release Meeting Minutes/2009-06-16

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