Difference between revisions of "Release Meeting Minutes/2008-05-05"

Latest revision as of 16:39, 10 January 2011

Minutes of weekly release meeting for 2008-05-05:

krb5-1.7 Goals:

Current:

• Kerberos Identity Management (KIM) API

• Enhanced GSSAPI errors

• Cross platform CCAPI

• GSS mech-glue plugin interface

• Multithreaded KDC

• Ticket request logging

• Master key rollover

Possible new goals based on consortium sponsor input:

• Code cleanup (architecture, formatting, etc)

• Incremental Propagation

• krb4 removal

• Service key rollover (both keys work during rollover period, currently have race condition)

Is master key rollover a special case of service key rollover? Not exactly the same: Correct key version needs to be used with KDB entries. Application servers can store multiple key versions in keytab. The commonality of the scenarios is useful to consider.

Bug reports:

• IPv6-only support

• UI issues with referrals (empty realm). Should be using reserved realm name to indicate referrals so developers and end users are not confused by the empty realm. Empty realm looks like a string manipulation bug.

• Database refactoring? Store KDC data using relational database features. Would be nice, too large a project for krb5-1.7

Code Cleanup Priorities:

ASN.1 -> looking at A2C to replace our implementation

Where are security advisories? krb4, KDC, RPC layer, ASN.1

What are security advisories? Mostly buffer overruns. Should start with support routines so buffer/string manipulation is standardized across krb5 sources.

New code: Database Abstraction Layer (DAL) and LDAP plugin. Pkinit contribution. Large sections of new code need better review and testing.

Should we require that new code contributions include comprehensive test suites? New hires will work on more testing for existing code.

Publish better coding standards/guidelines

Static Analysis Tools: Tools prefer a specific coding style. Using that style avoids false positives and makes the tools more useful.

Document interface stability levels in a more formal way than "random message sent to krbdev several years ago".

New Release Adoption:

Why are people staying with older releases?

• No compelling features and old releases work fine. (ie: "If it ain't broke...")

• Some sites want referrals for AD support but lots of traffic about bugs in referrals. May need principal re-writing (currently only have realm re-writing) to make referrals useful to sites.

• Security advisories reduce confidence

• Explicit ABI stability statement to increase developer confidence

• Static library support? Last seen in krb5-1.4

Communication:

We seem to have a communication problem. Not sure what is keeping people from upgrading or what they want.

Get more people involved on krbdev?

Use an announce list to publish upcoming release project proposals? Wiki is hard to track... RSS feed would be too much noise. Krbdev is too much noise for some sites. Use kerberos-announce? Should avoid sending mail more than twice a year. Make messages short with link to wiki with more detail.

How to get people more involved in beta testing process? Beta tester program? Should also have a guide (or white paper) on how to safely test a beta server in your environment without risk to the production server.

Project Policy:

How is project policy working out?

Need a "proposal" phase. Existing initial phase is a project plan. Create new proposal phase which only has a description of the project for consideration.

Instructions should be more explicit (step by step).

Currently project discussion can get split between wiki discussion pages and krbdev list. Confluence does not solve problem because it also has comments.

Use RT ticket associated with each proposal and put RT server (via mailing list) on krbdev? Then discussion can occur on list and it will still end up archived with the proposal's ticket. Wiki proposals can link to RT ticket and vice versa. Use special krb5-projects queue.

Consortium staff should take on more of the project proposal overhead. Existing process has too many steps for the person proposing the project. Discourages people from submitting if they have to go through 10 steps. Automate as much as possible to take workload off consortium staff/submitter.