Difference between revisions of "Release Meeting Minutes/2008-10-14"

Latest revision as of 16:42, 10 January 2011

Meeting notes for 2008-10-14:

Updates:

• Will has been working on setting up the Solaris zones features for testing krb5.
• Will is still experiencing a test suite failure in the db2 code, no progress on that. (It was 32-bit code running within a 64-bit OS, if that turns out to be relevant.)
• Will is working on the master key rollover project; it is coming along fine. He will update the project schedule and the testing plan on the wiki.
• Greg has installed Coverity and set up nightly builds; he still needs to set up user accounts and backups. He will start fixing the easier defects in order to get the count down this week.
• The Sun host->realm patch is currently waiting on legal confirmation from Sun; after that there are some changes to be made before committing it, which Greg will make.
• Alexis and Justin are working on KIM, hoping to have beta 1 done by the end of this week.
• Ken has been working on the ASN.1 code. He discovered that there were no tests for the PKINIT encoding and decoding functions, and upon investigation discovered that there are some bugs in that code. All of the PKINIT ASN.1 code needs to be carefully reviewed for correctness and consistency. That work may need to be deferred for now in order to complete the overall project.
• After the general ASN.1 work, Ken will work to resolve some the overall issues with PKINIT (reconciling the different implementations and making the code more correct).
• Zhanna is ready for code review on her cipher negotiation code, which will allow clients and application servers to negotiate a stronger cryptosystem than the ones offered by the KDC. Tom, Ken, and Greg will review this code.

Development road map -- crypto API:

• Sun would like a better crypto abstraction to allow adding new crypto implementations, and to allow using native crypto implementations in preference to the code shipped with krb5.
• One issue is fork safety. PKCS11 handles are not valid across forks, and it's also necessary to prevent two processes from using the same pseudo-random number stream. (The krb5 code already has some fork detection in the Yarrow code, but it's done with mutex-protected process global state.)
• We need to make the keyblock abstraction more opaque (says Tom).
• Unknown: are there users of the current crypto API such that we would need a compatibility shim?
• Apple and Sun have both developed changes to this API, so we need to reconcile those.

Development road map -- PKINIT:

• Sun currently has an issue with multiple versions of PKCS11 libraries being loaded into the same process, but can resolve it on their own.
• We need to be concerned with compatibility issues when we fix bugs in the ASN.1 encoding/decoding routines for PKINIT.

Development road map -- changes for Sun drop-in compatibility:

• Internationalization changes.
• Sun has changes to make parts of the krb5 code lint-clean because it is part of a kernel module.
• GSS context establishment is done in user space, while wrap/unwrap is done in kernel space, so making it easier to separate those pieces of code would be useful.
• Will will send some pointers to the OpenSolaris code for us to look at.
• Specific issues with lint:
  • It doesn't like it when we use inline functions.
  • It doesn't like it when we don't check function return values, which can sometimes be annoying.
  • It doesn't like the use of traditionally insecure functions like strcpy. Coverity doesn't like these either if you use the SECURE_CODING checker. Greg will look over these and write up some notes on what functions we should be using instead, for discussion on krbdev and later inclusion in the coding standards on the wiki.
• Sun also has 74 calls to their auditing system. There was some discussion about what to do about these; we may want to make our existing logging more formalized and possibly add a plug-in layer for logging and auditing.
• We would like to move in the direction of using fewer #ifdefs whenever possible; that should go into the coding guidelines as well.