TomYu at 03:57, 4 January 2011

2011-01-04T03:57:32Z

TomYu at 18:55, 21 June 2009

2009-06-21T18:55:33Z

Ghudson: 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 (...

2009-06-17T03:44:16Z

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 (...

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 (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 state (only for uses requiring collision resistance) but does encourage the use of SHA2

← Older revision		Revision as of 03:57, 4 January 2011
Line 1:		Line 1:
		+	{{minutes\|2009}}
	1.8 release:		1.8 release:
	* Feature freeze around January 1		* Feature freeze around January 1

@@ Line 21: / Line 21: @@
 ** 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 state (only for uses requiring collision resistance) but does encourage the use of SHA2
+** 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

Release Meeting Minutes/2009-06-16 - Revision history

TomYu at 03:57, 4 January 2011

TomYu at 18:55, 21 June 2009

Ghudson: 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 (...