Difference between revisions of "Release Meeting Minutes/2009-06-16"

From K5Wiki
Jump to: navigation, search
Line 1: Line 1:
1.8 release:
1.8 release:
* Feature freeze around January 1
* Feature freeze around January 1

Latest revision as of 23:57, 3 January 2011

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