K5Wiki - User contributions [en]

Main Page

2011-11-21T04:01:49Z

KenRaeburn: Undo revision 4458 by Autumnqxho (Talk)

__NOTOC__
'''K5Wiki''' is a wiki supporting the development of [[MIT Kerberos]], a reference implementation of [[wp:Kerberos (protocol)|the Kerberos network authentication protocol]]. MIT Kerberos is a project of the [http://www.kerberos.org/ MIT Kerberos Consortium].

This wiki serves both as a place for coordination of development efforts on MIT Kerberos and as a means for potential contributors and other interested people to become more involved with MIT Kerberos development. This wiki does not focus on the needs for the average end user, but it may nevertheless contain information that is useful to advanced users, such as system administrators who wish to make customizations.

What can this wiki do for you?
* I have a [[Asking questions|question]]
* I want to [[Writing applications|write Kerberos application software]]
* I want to [[Reporting bugs|report bugs]]
* I want to [[Fixing bugs|fix bugs]]
* I want to [[Learning about the code|learn more about the code]]
* I have [[Suggesting enhancements|ideas for enhancements]]
* I want to [[Contributing code|contribute code]]
* I want to [[K5Wiki:Todo|help to improve this wiki]]

== Releases ==

The current release is [http://web.mit.edu/kerberos/krb5-1.9/ krb5-1.9].

* [[Release 1.9 | Release 1.9 goals]]

Additional information on future releases:

* Development [[roadmap]]

== Users ==

We recommend that end users use MIT Kerberos software packages built by their operating system vendor if possible, and use support resources provided by their site or by their vendor. For those users (typically system administrators) who have a need to build MIT Kerberos from source code, we have some resources available on this wiki.

* [[Building]] the MIT Kerberos software
* [[Reporting bugs]]
* [[Suggesting enhancements]]
* More [[user resources]]

== System administrators ==

We also recommend that most system administrators use MIT Kerberos software packages from their operating system vendor if possible.

* [[Building]] the MIT Kerberos software
* [[Reporting bugs]]
* [[Suggesting enhancements]]
* [[IPv6]] support status
* More [[sysadmin resources]]

== Developers ==

Developers can include end users who have a need to customize the MIT Kerberos source code, or who would like to contribute patches for new features or for bug fixes.

* [[Developer resources]]

=== Contributing ===

* [[How to contribute]] to the MIT Kerberos software
* [[Fixing bugs]]
* [[Suggesting enhancements]]
* [[Contributing code]]

=== Background information ===

* [[:Category:Policies|Policies for development]]
* [[:Category:Lore|Lore]]

=== Code quality ===

* [[Coding style]]
* [[Test-driven development]]
* [[Manual_Testing|Manual testing procedures]]

=== Planning ===

* Development [[roadmap]]
* [[Projects]]

=== Communication ===

* [[Release_Meeting_Minutes|Release Meeting Minutes]]
* [[IRC and Jabber]]
* [http://blog.kerberos.org/ Blog]

== Additional information ==

* [[K5Wiki:Todo|A todo list for work needing doing on this wiki]]
* [[Application_Maintenance|Notes on maintenance of the krb5 telnet/rlogin/gssftp applications]]

We look forward to your contributions to K5Wiki and MIT Kerberos.

Release Meeting Minutes/2011-01-18

2011-01-28T21:04:01Z

KenRaeburn:

{{minutes|2011}}
Greg Hudson, Tom Yu, Zhanna Tsitkova, Simo Sorce, Will Fiveash

;Simo: Explain why there are 2 parts for each function doc.

;Zhanna: Parameter names should match in header and .c file.

;Simo: Not clear how to submit doc. In other projects, submissions to mailing list (main dev list).

[ Discussion about whether krbdev is too high traffic. We might use the bug tracker and create a separate RT queue if there's too much traffic. ]

Projects/Documentation Tasks

2011-01-14T06:23:18Z

KenRaeburn: /* API documentation */ remove extra nameless column on right edge of tables

{{project-early}}

== Purpose ==

To keep track of the various tasks that need to be documented such as function documentation, administration, troubleshooting etc.

=== API documentation ===

{| class="wikitable"
|+ Matrix of Document-Type VS Intended Readership
|-
! Doc-type/Reader
! Architectural Guide
! Setup & Config of Kerberos
! Admin & Operations of Kerberos
! Custom Build
! API Description
! API Details
|-
|-
| End-users || || || || || ||
|-
| Architects || || || || || ||
|-
|System Admins || || || || || ||
|-
|Application Developers || || || || || ||
|-
|GSSAPI Developers || || || || || ||
|-
|Kerberos Developers || || || || || ||
|}

{| class="wikitable"
|+ Tier 1 - most commonly used API functions (in alphabetical order)
|-
! API
! who writes?
! who reviews?
! reviewed?
! comments
|-
|-
| krb5_build_principal || || || ||
|-
| krb5_build_principal || || || ||
|-
|krb5_build_principal_alloc_val || || || ||
|-
| krb5_build_principal_ext || || || ||
|-
| krb5_cc_close || || || ||
|-
| krb5_cc_default || || || ||
|-
| krb5_cc_default_name || || || ||
|-
| krb5_cc_destroy || || || ||
|-
| krb5_cc_dup || || || ||
|-
| krb5_cc_get_name || || || ||
|-
| krb5_cc_get_principal || || || ||
|-
| krb5_cc_get_type || || || ||
|-
| krb5_cc_initialize || || || ||
|-
| krb5_cc_new_unique || || || ||
|-
| krb5_cc_resolve || || || ||
|-
| krb5_change_password || || || ||
|-
| krb5_free_context || || || ||
|-
| krb5_free_error_message || || || ||
|-
| krb5_free_principal || || || ||
|-
| krb5_fwd_tgt_cred || || || ||
|-
| krb5_get_default_realm || || || ||
|-
| krb5_get_error_message || || || ||
|-
| krb5_get_host_realm || || || ||
|-
| krb5_get_credentials || || || ||
|-
| krb5_get_fallback_host_realm || || || ||
|-
| krb5_get_init_creds_keytab || || || ||
|-
| krb5_get_init_creds_opt_alloc || || || ||
|-
| krb5_get_init_creds_opt_free || || || ||
|-
| krb5_get_init_creds_opt_get_fast_flags || || || ||
|-
| krb5_get_init_creds_opt_init || || || ||
|-
| krb5_get_init_creds_opt_set_address_list || || || ||
|-
| krb5_get_init_creds_opt_set_anonymous || || || ||
|-
| krb5_get_init_creds_opt_set_canonicalize || || || ||
|-
| krb5_get_init_creds_opt_set_change_password_prompt || || || ||
|-
| krb5_get_init_creds_opt_set_etype_list || || || ||
|-
| krb5_get_init_creds_opt_set_expire_callback || || || ||
|-
| krb5_get_init_creds_opt_set_fast_ccache || || || ||
|-
| krb5_get_init_creds_opt_set_fast_ccache_name || || || ||
|-
| krb5_get_init_creds_opt_set_fast_flags || || || ||
|-
| krb5_get_init_creds_opt_set_forwardable || || || ||
|-
| krb5_get_init_creds_opt_set_out_ccache || || || ||
|-
| krb5_get_init_creds_opt_set_pa || || || ||
|-
| krb5_get_init_creds_opt_set_preauth_list || || || ||
|-
| krb5_get_init_creds_opt_set_proxiable || || || ||
|-
| krb5_get_init_creds_opt_set_renew_life || || || ||
|-
| krb5_get_init_creds_opt_set_salt || || || ||
|-
| krb5_get_init_creds_opt_set_tkt_life || || || ||
|-
| krb5_get_init_creds_password || || || ||
|-
| krb5_get_profile || || || ||
|-
| krb5_get_prompt_types || || || ||
|-
| krb5_get_renewed_creds || || || ||
|-
| krb5_get_validated_creds || || || ||
|-
| krb5_init_context || || || ||
|-
| krb5_init_secure_context || || || ||
|-
| krb5_is_config_principal || || || ||
|-
| krb5_is_thread_safe || || || ||
|-
| krb5_kt_close || || || ||
|-
| krb5_kt_default || || || ||
|-
| krb5_kt_default_name || || || ||
|-
| krb5_kt_get_name || || || ||
|-
| krb5_kt_get_type || || || ||
|-
| krb5_kt_resolve || || || ||
|-
| krb5_kuserok || || || ||
|-
| krb5_parse_name || || || ||
|-
| krb5_parse_name_flags || || || ||
|-
| krb5_principal_compare || || || ||
|-
| krb5_principal_compare_any_realm || || || ||
|-
| krb5_principal_compare_flags || || || ||
|-
| krb5_prompter_posix || || || ||
|-
| krb5_realm_compare || || || ||
|-
| krb5_recvauth || || || ||
|-
| krb5_recvauth_version || || || ||
|-
| krb5_set_default_realm || || || ||
|-
| krb5_set_password || || || ||
|-
| krb5_set_password_using_ccache || || || ||
|-
| krb5_set_principal_realm || || || ||
|-
| krb5_set_trace_callback || || || ||
|-
| krb5_set_trace_filename || || || ||
|-
| krb5_sname_to_principal || || || ||
|-
| krb5_unparse_name || || || ||
|-
| krb5_unparse_name_ext || || || ||
|-
| krb5_unparse_name_flags || || || ||
|-
| krb5_unparse_name_flags_ext || || || ||
|-
| krb5_us_timeofday || || || ||
|-
| krb5_verify_authdata_kdc_issued || || || ||
|-
|}

Projects/Kerberos Documentation

2010-12-07T20:14:47Z

KenRaeburn: /* Documenting functions */

{{project-early}}

== Purpose ==

The goal of the project is to create an infrastructure and process for the future development of the extensive Kerberos documentation.

The actualized documentation will be useful for developers and administrators, both for experienced ones and newcomers. It will address the following topics:

* Complete reference - API, internal functions, data types, macros
* Tutorial for application developers - description on various tasks such as working with credentials, read and verify message, etc
* Cookbook for administrators - Installation, configuration, troubleshooting
* Contributions to Kerberos code - topics on how to write plugins, kerberize cloud, etc

The documentation will be built incrementally. We will analyze what works and what doesn't and correct the course of action as needed.

== Details of source documentation ==

==== Documenting functions ====

'''Part_1'''

The following fields ''must'' be included in the function documentation and should reside in the source code (as the most useful for those who update the code and fix the bugs) :

# Function signature
# Brief function description
# Arguments - [in/out] with description
# Return value description
# Detailed description (optional)

'''Part_2'''

The ''optional'' fields may include:

# ''See also'' section to refer to the related functions,
# ''Note'' section to highlight the specifics of the behaivor
# Examples of the usage
# Snap-shot of the real code involving this function
# Links to KRB5 Wiki Project page, krbdev discussion, RFC document or its section etc
# Version of Kerberos when fuction was introduced or became obsolete

This effectively means that we expect the Doxygen style comments in the headers in the following format:

/**
* @brief Some brief descr
*
* Optional long and very detailed description
*
* @param[in] context A krb5 library context (see krb5_Z())
*
* @return Something useful
*/
char * KRB5_CALLCONV
krb5_X ( krb5_context context)

Also, when available, we suggest to have Part_2 information associated with the particular function in ReST format. It will be kept in the separate file (one file per function). For example:

* Warnings and suggestions
Warn about any potential mistakes.
Point to other useful places.

* Links to RFC, wiki Projects, krbdev discussions
:rfc:4120
Or if you want to reffer to the specific section of the RFC use the following notation: :rfc:4120#section-5.2
Or link to Kerberos Project page, for example, Disable_DES project <http://k5wiki.kerberos.org/wiki/Projects/Disable_DES>

* Example
The place for the function usage examples

'''Workflow: Putting Part_1 and Part_2 together'''

# Configure Doxygen to generate output both in xml and html formats. Run Doxygen.
# For each function and data type generate document in ReST format. It is expected that it contains information from Part_1. For the function ''krb5_X()'' lets call it ''krb5_X_p1''.
# If the Part_2 documentation for ''krb5_X()'' has been already written, there is a file called ''krb5_X_p2.rst'' in the designated directory. If not - nothing happens.
# Concatenate ''krb5_X_p1'' and ''krb5_X_p2.rst'' (if it exists), add the link to Doxygen generated documentation for this function in html format (generated automatically) and save as a file ''krb5_X.rst''.
# File ''krb5_X.rst'' can be used as input for Sphinx

NOTE: We provide Python script to automate steps 2-4.

==== Documenting data types ====

TODO

== How to contribute ==

# The core team - the administrator - posts the initial list of the tasks (such as API, admin tasks, "How to"-s etc) and further supports it.
# Community can suggest new tasks
# The core team provides templates that, if helpful, may be used by the documentation writers. The most desirable format for the contributed documents is ReST as the easiest to integrate with the mainstream documentation.
# Community can provide the feedback on the documented tasks. There will be a designated mail box krbdoc@mit.edu for this purpose

== Tools ==

* Doxygen 1.7.2 <http://www.stack.nl/~dimitri/doxygen/index.html>
* Sphinx 1.0.4 <http://sphinx.pocoo.org>
* Python 2.5+
* Restructured Text markup <http://docutils.sourceforge.net/docs/user/rst/quickstart.html>

Projects/Parallel KDC

2010-03-27T19:50:58Z

KenRaeburn: /* Design of Proposed Solution */

{{project-early}}

== Problem ==

The KDC is a single-threaded daemon--once it receives a complete request from a client, it fully processes that request before receiving another. The performance consequences of this are threefold:

* Only one CPU services KDC requests, including cryptography operations.
* When the KDC is reading data from disk (such as the replay cache or a BDB database), it does nothing else.
* If the KDB module retrieves data from a remote source (such as an LDAP query), the KDC does nothing while waiting for a reply.

Most KDCs experience only moderate load and can service requests quickly. In some circumstances, higher performance may be required.

== Candidate Solutions ==

There are four possible solutions, the first of which is already possible:

* The realm administrator can run multiple KDC processes on the same host, each listening on a different port, each accessing the same database. This is possible with the current implementation, and SRV records can be used to avoid the need for client configuration; however, it does not yield optimal performance. Each client request will select a port without knowing whether the KDC process servicing that port is busy, and will wait for a timeout before trying another port. Moreover, MIT krb5 client code does not implement randomization of equal-priority SRV records, so randomization of SRV responses by the DNS infrastructure would be necessary for load-balancing to occur, and such randomization is sometimes defeated by caching. Parallelism is limited to the number of KDC processes.

* We could make the KDC event-oriented. This approach would require refactoring the entire KDC code base and all KDB modules. The DAL would have to provide KDB modules access to the listen_and_process main loop, and all DAL requests would have to be structured with callbacks or other mechanisms to allow the answer to arrive after further iterations of the main loop. This approach would only solve the problem of allowing the KDC to perform work while waiting for remote data sources such as LDAP; it would not allow multiple CPUs to service KDC requests or allow the KDC to perform work while waiting for disk accesses to complete.

* We could make the KDC multithreaded. This approach would require eliminating all use of global state (in particular, the kdc_active_realm variable and all of the macros such as kdc_context which derive from it) and ensuring that all library code used by the KDC is thread-safe. Any mistakes in thread-safety might result in difficult-to-debug race conditions, some of which might have security consequences.

* We could make the KDC use a multi-process worker model. After setting up its initial state including listener sockets, the KDC would fork multiple subprocesses. The set of idle subprocesses would compete for UDP packets or incoming TCP connections on the listener sockets, invisibly to clients. Once a worker process has obtained a request, it would service it according to the current single-threaded logic. Parallelism would be limited to the number of worker processes.

This project proposes to implement the fourth option, as it requires minimal code changes and does not introduce much additional risk.

== Design of Proposed Solution ==

A new option would need to be added to the getopt() loop in initialize_realms() to specify the number of worker threads. The -w option is a reasonable option since it is currently unused.

Code to create the worker processes would be invoked from main() after the call to write_pid_file(). The parent process would act as a proxy for SIGTERM and SIGHUP so that killing the pid in the pid file terminates or signals all worker processes.

The network socket code would likely need to set the listening sockets to non-blocking, and process_packet() would need to ignore EAGAIN errors instead of logging them.

When the host network is reconfigured, the KDC must rebind its UDP listening sockets, on platforms with no IP_PKTINFO support. (This is necessary to send UDP replies from the same address we received the request at.) This cannot be done in the worker subprocesses since multiple processes cannot all bind to the same port, so workers would have to be terminated and restarted to perform reconfiguration. Alternatively, the network reconfiguration support could be disabled when worker processes are used, or removed entirely; an inventory of IP_PKTINFO platform support would be helpful to evaluate the viability of these options.

The KDB module should be independently opened in each worker process (rather than opening it once and cloning the resulting process state). It is also probably a good idea to open and then close the KDB module in the supervisor, prior to starting worker processes, in order to get a more controlled failure if the KDB module is misconfigured.

The logging code would need to be examined to make sure that concurrent access to the same logging sinks would not create problems.

Additional attention to bug #1671 (no file locking used by replay cache) may be necessary to evaluate whether there is a security impact on a multi-process KDC, keeping in mind that allowing one replay to each independent KDC processes is typically not considered a serious security threat in master/slave scenarios.

== Testing Plan ==

In most test scenarios, requests are processed too quickly by the KDC to measure any difference in behavior from a multi-process worker model. It should be possible to test this by hand by temporarily modifying the BDB back end to sleep() for a minute when looking up a particular principal name such as "slowuser". While testing, note that libkrb5 will retry requests after a timeout, so a single "kinit slowuser" will cause multiple worker processes to block unless the retry logic is disabled in the client code. Client retry logic can be disabled in lib/krb5/os/sendto_kdc.c by changing MAX_PASS from 3 to 1 and changing all assignments to socktype2 to 0 (e.g. instead of SOCK_STREAM).

Automated testing of this functionality would be pretty tricky; we would need a special stub KDB back end to cause worker processes to block, as well as a way to control the client retry loop.

== Schedule ==

This project is currently on the back burner.

Projects/Random Salt Generation

2009-07-26T07:31:57Z

KenRaeburn: /* Salt generation */ more observations on des_string_to_key

{{project-early}}

==Summary==

The idea of this project is to deprecate the notion of "salt type" and generate a random salt for all new principals. Because of the associated complications, there are no resources allocated to the project at this time.

==Background==

When Kerberos keys are derived from password, they are usually combined with a salt, to prevent attackers from building up a pre-calculated dictionary of keys based on common passwords. The default salt is specified by RFC 4120 as "the concatenation of the principal's realm and name components, in order, with no separators" but the KDC can also provide an alternate salt to the client in an AS-REP. Note that RC4 keys are are an exception; they depend only on the password, not on a salt.

The MIT KDC has an internal concept of "salt types" defined by the DB abstraction layer. A salt type of SPECIAL indicates that the salt is stored in the database alongside the key; other salt types indicate various ways of computing the salt from the principal. NORMAL indicates the default salt, but as of 1.7, the KDC explicitly communicates the salt to the client even if the salt type is NORMAL. Salt types can be determined using enctype:salttype pairs either in the supported_enctypes krb5.conf variable or in the -e option to the add_principal or change_password kadmin commands.

==Benefits==

Generating random salts for keys has the following benefits:

* Easier principal renaming -- currently when a principal with a computed salt is renamed, the old salt must be computed and stored in the DB entry. This would be unnecessary for principals created with random salts. Of course, the code to compute and store the old salt would still be necessary because of legacy DB entries.
* If a principal is renamed, the stored old value of the default salt would expose the old name of the principal. In general this would not be sensitive information, but in rare cases it might be. Randomly generated salts would avoid this exposure.
* Simpler principal canonicalization -- randomly generated salts avoid any ambiguity when a principal is canonicalized or a key set is shared between multiple canonical principal names.
* Simpler configuration -- without the concept of salt types, supported_enctypes can be a list of enctypes just like the other enctype variables. This would allow supported enctypes to take advantage of the syntax extensions from [[Projects/Enctype_config_enhancements]].

==Complications==

* Our password history checking currently does not work if the salt changes (except for RC4 keys which are salt-independent); it only compares new keys against old keys. This is arguably a bug; in any event, it would have to be changed to try generating keys wit the new password and old salts to match against old keys.
* Although RFC 4120 cautions that "it is not possible to generate a user's key reliably given a pass phrase without contacting the KDC, since it will not be known whether alternate salt or parameter values are required," we have a ktutil command to do so anyway, which assumes the default salt. This would need to be addressed, perhaps by making ktutil acquire credentials to determine the salt.
* Cross-realm TGTs are typically entered into both KDC databases using the same password. If they use different salts, they won't have the same keys, and won't work. This would have to be addressed, perhaps via an option to add_principal to use a fixed salt or the default salt.
* There may also be an issue with the creation of machine and service accounts for Windows, according to http://mailman.mit.edu/pipermail/krbdev/2009-July/007839.html

==Salt generation==

Salts should use only printable ASCII characters, as they must be transmitted to the client in a KerberosString.

Ken Raeburn made the following notes about the length of the salt:

* DES string-to-key uses a fan-fold technique that's likely to make some of the salt bits cancel each other out, depending on the password length; I'd suggest at least 112 bits but you can probably stare at it and figure it out for sure.
* DES3 uses 168-fold, where the efficacy of the mixing is again determined in part by the password length. It's better, but I'm not convinced 168 random bits expanded to a salt string will let you cover the whole possible key space (which I think would be desirable... though I suppose not absolutely required). I looked at it a while back but don't remember the specifics. It may just be that when password+salt has a length that's a multiple of 168 the fixed bits due to use of printable ASCII are just doomed to line up and cut powers of 2 off the possible generated key space.
* AES uses PBKDF2 with SHA-1; that's probably fine with 160 random bits. (Even for a 128-bit key, I'd probably use 160 random bits, to try to get maximum coverage of the output space for a given password before the truncation, but haven't thought about it much. It's not like it couldn't be changed later if more careful analysis determines that 128 random bits are sufficient.)
* Hm.. for DES I take it back -- you don't need 112 random bits, but 16 randomized printable-ASCII bytes; more than that and the non-fixed bits just start getting xor'ed with each other and don't help. You could tune it a bit by looking at the bit-value probabilities for printable ASCII and where they're going to get xor'ed, and see if you can guarantee that at least one of the bits going in has exactly 0.5 probability of being set.
** After some more contemplation, I think 16 characters where the low four bits are randomly chosen and the upper bits fixed (''e.g.'', 0x40-0x4F), 64 random bits total, after the fan-fold and XOR, may suffice to guarantee complete possible coverage of and flat distribution over the 56-bit intermediate key space; half the bytes will be bit-reversed for the XOR, randomizing the upper bits of the intermediate result, and while we don't know which ones, we can show that for 16 bytes, exactly one will contribute normally and exactly one bit-reversed will contribute to a given byte of the intermediate output. It may be that only, say, the even bytes need four random bits and odd ones can get away with three (because we're reversing and combining 7-bit "bytes"), getting us down to 56 random bits of input, but that should be analyzed more closely to be sure. But, see below re: "whatever" and not caring too much. :-) --[[User:KenRaeburn|KenRaeburn]] 03:31, 26 July 2009 (EDT)
* (In case it's not clear why I'm thinking about that, consider two-bit values permitted to vary from 0 to 2. Chosen randomly from the range, the low bit has a 2/3 probability of being set. If you xor two of these together, the low bit has a 2*2/3*1/3 = 4/9 probability of being set, giving uneven distribution across the possible resulting 2-bit strings. For printable ASCII, c&0x70 will range from 2-7 and 0x7f will presumably be left out; it's not as skewed as my example, but it's not an even distribution. Then again, DES is being phased out, and choosing 16 bytes randomly from 0x20-0x7e is still a lot better than what we have now, so, whatever.)
* And on the more general salt-length issue, I think I've mentioned it before, but if the salts are big enough to ensure coverage of most or all of the possible key space even with weak passwords, an attacker can't effectively build up dictionaries of common passwords plus all possible salts, or cutting large ranges of possible keys out of a brute-force search. It's probably true that multiplying the work factor by 2**64 or less would be adequate, as long as we can be confident that there aren't classes of salt strings or salt+password combinations that the attacker can handle efficiently for certain cryptosystems (e.g., because certain pairs of bits only influence the result via their xor, making them effectively single bits). Like I already said, the details can be tuned later depending on risk analysis. And sending more bits rather than fewer until the analysis is done doesn't really cost much.

Test suite

2009-06-30T12:55:59Z

KenRaeburn: /* Software needed for running "make check" */

[[Category:Lore]]

== Procedure ==
* ''svn checkout svn://anonsvn.mit.edu/krb5/trunk''
* Navigate to trunk/src
* ''util/reconf''
* ''./configure''
* ''make''
* ''make check''
* ''make install'' (as root, unless you gave a --prefix option to configure which you can write to as yourself)

== Software needed for running "make check" ==

On Ubuntu or Debian systems, a number of packages need to be installed in order for "make check" to function. These include:

* dejagnu
* expect
* tcl
* tcl-dev (needed by test programs that are extensions to the tcl program)
* portmap (needed by lib/rpc-unit-test)
* csh (or maybe tcsh; needed by some of the libdb2 tests)
* g++
* byacc or bison (bison if you configure with "--enable-maintainer-mode" and need to rebuild certain of the parsers where we check in the generated C files)
* ncurses-dev
* libtool libltd13-dev

== Known test suite issues ==

On Linux systems, sometimes the <code>--disable-rpath</code> option to <code>configure</code> is required in order to avoid problems with previously-installed versions of MIT krb5. Alternatively, you can run "make install" before "make check".

The calls to krb5_c_random_os_entropy that pass the value 1 in the <code>strong</code> argument, which causes the library to read from the strong OS random number source, can cause stalls and timeouts in the test suite. Changing those calls to pass 0 instead will reduce the stalls. We need to have a better way to disable the reading of strong random numbers during tests. This is primarily a problem on Linux systems.

If an existing kdc.conf exists in the "installed" location, it can disrupt the automated tests, especially if it contains syntax errors.

On recent Debian or Ubuntu systems, a bug in <code>expect</code> that can cause stalls in the dejagnu parts of the test suite is documented at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421187

The testing user's shell must be listed in /etc/shells or the gssftp tests will fail. This will cease to be a concern for the main krb5 test suite if and when the applications are unbundled into a separate package.

The rlogin and telnet dejagnu tests require root access; without it, the test suite will skip those tests. To run these tests, you can either run the test suite as root, or arrange for "rlogin <localhostname> -l root -x" to succeed. (The environment variables RLOGIN and RLOGIN_FLAGS can override the "rlogin" and "-x" parts of that command line.) This will also cease to be a concern for the main krb5 test suite if and when the applications are unbundled.

Test suite

2009-06-30T12:54:20Z

KenRaeburn: /* Software needed for running "make check" */ bison's only for maintainer mode

[[Category:Lore]]

== Procedure ==
* ''svn checkout svn://anonsvn.mit.edu/krb5/trunk''
* Navigate to trunk/src
* ''util/reconf''
* ''./configure''
* ''make''
* ''make check''
* ''make install'' (as root, unless you gave a --prefix option to configure which you can write to as yourself)

== Software needed for running "make check" ==

On Ubuntu or Debian systems, a number of packages need to be installed in order for "make check" to function. These include:

* dejagnu
* expect
* tcl
* tcl-dev (needed by test programs that are extensions to the tcl program)
* portmap (needed by lib/rpc-unit-test)
* csh (or maybe tcsh; needed by some of the libdb2 tests)
* g++
* byacc (or bison if you configure with "--enable-maintainer-mode" and need to rebuild one of the parsers where we check in the generated C files)
* ncurses-dev
* libtool libltd13-dev

== Known test suite issues ==

On Linux systems, sometimes the <code>--disable-rpath</code> option to <code>configure</code> is required in order to avoid problems with previously-installed versions of MIT krb5. Alternatively, you can run "make install" before "make check".

The calls to krb5_c_random_os_entropy that pass the value 1 in the <code>strong</code> argument, which causes the library to read from the strong OS random number source, can cause stalls and timeouts in the test suite. Changing those calls to pass 0 instead will reduce the stalls. We need to have a better way to disable the reading of strong random numbers during tests. This is primarily a problem on Linux systems.

If an existing kdc.conf exists in the "installed" location, it can disrupt the automated tests, especially if it contains syntax errors.

On recent Debian or Ubuntu systems, a bug in <code>expect</code> that can cause stalls in the dejagnu parts of the test suite is documented at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421187

The testing user's shell must be listed in /etc/shells or the gssftp tests will fail. This will cease to be a concern for the main krb5 test suite if and when the applications are unbundled into a separate package.

The rlogin and telnet dejagnu tests require root access; without it, the test suite will skip those tests. To run these tests, you can either run the test suite as root, or arrange for "rlogin <localhostname> -l root -x" to succeed. (The environment variables RLOGIN and RLOGIN_FLAGS can override the "rlogin" and "-x" parts of that command line.) This will also cease to be a concern for the main krb5 test suite if and when the applications are unbundled.

Debugging tips

2009-04-30T15:46:18Z

KenRaeburn: /* Compile-Time Flags */

This page documents krb5-specific techniques which may help debug problems. Feel free to add additional techniques.

As always, the basic tools are helpful: debuggers like gdb or dbx, system call tracing tools like strace or truss, shared library tracing tools like ltrace or sotruss, and memory debugging tools like valgrind or Purify.

==Compile-Time Flags==

You can build the tree with additional flags like so:

make clean
make CPPFLAGS=-DFLAGNAME

or in a new build tree:

.../configure CPPFLAGS=-DFLAGNAME
make

===DEBUG_ERROR_LOCATIONS===

The DEBUG_ERROR_LOCATIONS flag causes verbose error messages generated from the krb5 libraries to include file and line number information. It can be useful if you're having trouble tracking down where an error message is generated. It will not work in cases where an error code is generated with no call to krb5_set_error_message or krb5int_set_error; in that case you will have to track it down the slow way with gdb or whatever. If you are seeing an error with no corresponding krb5_set_error_message_call, consider whether the error case is "likely" and perhaps add a krb5_set_error_message to make it clearer what is going on.

==Debugging the KDC==

krb5kdc can be run with the -n flag to prevent it from backgrounding itself, allowing you to set breakpoints before it starts. Alternatively, you can attach to the process after it forks. The process_as_req and process_tgs_req functions are the entry points to handling client requests.

Release Meeting Minutes

2009-03-21T18:32:36Z

KenRaeburn: /* January 2009 */

Public minutes of Kerberos Consortium Release Meetings arranged in reverse chronological order:

==February 2009==

[[Release Meeting Minutes/2009-02-03 | February 3, 2009 (2009-02-03)]]

==January 2009==

[[Release Meeting Minutes/2009-01-27 | January 27, 2009 (2009-01-27)]]

[[Release Meeting Minutes/2009-01-13 | January 13, 2009 (2009-01-13)]]

[[Release Meeting Minutes/2009-01-06 | January 6, 2009 (2009-01-06)]]

==October 2008==

[[Release Meeting Minutes/2008-10-14 | October 14, 2008 (2008-10-14)]]

[[Release Meeting Minutes/2008-10-07 | October 7, 2008 (2008-10-07)]]

==September 2008==

[[Release Meeting Minutes/2008-09-30 | September 30, 2008 (2008-09-30)]]

[[Release Meeting Minutes/2008-09-09 | September 9, 2008 (2008-09-09)]]

[[Release Meeting Minutes/2008-09-02 | September 2, 2008 (2008-09-02)]]

==August 2008==

[[Release Meeting Minutes/2008-08-26 | August 26, 2008 (2008-08-26)]]

[[Release Meeting Minutes/2008-08-04 | August 4, 2008 (2008-08-04)]]

==July 2008==

[[Release Meeting Minutes/2008-07-21 | July 21, 2008 (2008-07-21)]]

[[Release Meeting Minutes/2008-07-14 | July 14, 2008 (2008-07-14)]]

[[Release Meeting Minutes/2008-07-07 | July 7, 2008 (2008-07-07)]]

==June 2008==

[[Release Meeting Minutes/2008-06-30 | June 30, 2008 (2008-06-30)]]

[[Release Meeting Minutes/2008-06-23 | June 23, 2008 (2008-06-23)]]

[[Release Meeting Minutes/2008-06-16 | June 16, 2008 (2008-06-16)]]

==May 2008==

[[Release Meeting Minutes/2008-05-19 | May 19, 2008 (2008-05-19)]]

[[Release Meeting Minutes/2008-05-12 | May 12, 2008 (2008-05-12)]]

[[Release Meeting Minutes/2008-05-05 | May 5, 2008 (2008-05-05)]]

==April 2008==
[[Release Meeting Minutes/2008-04-28 | April 28, 2008 (2008-04-28)]]

[[Release Meeting Minutes/2008-04-14 | April 14, 2008 (2008-04-14)]]

==March 2008==
[[Release Meeting Minutes/2008-03-31 |March 31, 2008 (2008-03-31)]]

[[Release Meeting Minutes/2008-03-24 |March 24, 2008 (2008-03-24)]]

[[Release Meeting Minutes/2008-03-17 |March 17, 2008 (2008-03-17)]]

[[Release Meeting Minutes/2008-03-10 |March 10, 2008 (2008-03-10)]]

==February 2008==
[[Release Meeting Minutes/2008-02-04 |February 4, 2008 (2008-02-04)]]

==January 2008==
[[Release Meeting Minutes/2008-01-28 |January 28, 2008 (2008-01-28)]]

[[Release Meeting Minutes/2008-01-07 |January 7, 2008 (2008-01-07)]]

==December 2007==
[[Release Meeting Minutes/2007-12-17|December 17, 2007 (2007-12-17)]]

[[Release Meeting Minutes/2007-12-10|December 10, 2007 (2007-12-10)]]

Release Meeting Minutes/2009-01-27

2009-03-21T18:32:06Z

KenRaeburn: New page: '''Release Meeting Minutes for 2009-01-27''' Present: Zhanna, Greg, Tom, Thomas, Ken, Will Updates: * Ken: reviewed Will's code, working on update_princ_encryption * Tom: doing disable D...

'''Release Meeting Minutes for 2009-01-27'''

Present: Zhanna, Greg, Tom, Thomas, Ken, Will

Updates:
* Ken: reviewed Will's code, working on update_princ_encryption
* Tom: doing disable DES by default capability, simpler version with allow_weak_crypto config var; working on bug db, release notes
* Zhanna: referrals more or less done, working on bugs
* Greg: Will be working on "kdb5_util sync_stash" command after spinning up on mkey_migrate; should it be renamed or merged into "kdb5_util stash"?
* Will: "kdb5_util dump" mkey convert option - tried implementing with some add_mkey code, running into a deadlock problem; looks like db2 back end has mutex locks in a couple places where not needed, will fix. Most of Ken's major review points have been addressed. Will address mkey-convert, do more testing, tackle "kdb5_util purge_mkeys". Can run "make check" successfully. Needs Ken's script for filtering valgrind log files to find errors.

1.7 planning:
* Schedule for cut = Friday noon. Try to wrap things up by Thursday.
* Will can add tests for mkey-migration later, but needs to get a schedule to Tom by Friday.

Release Meeting Minutes/2009-01-06

2009-03-21T18:32:03Z

KenRaeburn: New page: '''Meeting notes for 2009-01-06''' Present: Greg H, Zhanna T, Steve B, Tom Y, Ken R, Sam H, Will F Updates: * Will: Estimate ~17 days' work left. Might help to get someone to review wor...

'''Meeting notes for 2009-01-06'''

Present: Greg H, Zhanna T, Steve B, Tom Y, Ken R, Sam H, Will F

Updates:
* Will: Estimate ~17 days' work left. Might help to get someone to review work done so far, may be able to get changes to the trunk by the 31st. Will try to commit work done so far to branch in MIT repository for review. Still working with same design previously discussed. Might be able to get some manpower to help out.
* Sam: Luke & Sam's work is about 95% done. Open issues: Project writeup for non-DCE GSSAPI changes; get aliasing project writeup into review; enctype nego writeup is in review as of today. Want to get to some more reviewing of code for some of the very latest changes, but probably okay if that doesn't happen. Still need an answer: Luke's code adds encrypted pa-data structure for referral data, changing an ABI, probably not in a horrible way, but we'd need to discuss it, should at least run by Apple and Sun. We might be able to just take it out. Waiting on answer to a question from Larry regarding cases where Windows behavior doesn't match Larry's understanding; might affect this. ...Some discussion of Luke's statement of work and current states of things....
* Zhanna: Working on domain_realm mapping in KDC, close to done.
* Greg: Working on replay cache hashes, about half done. Might want to change some internal interfaces to the replay cache. Hash values may be needed only for rd-req, not rd-safe or rd-priv cases where we don't know if there are any collisions happening in pracice.
* Ken: Looking over Luke & Sam's changes, have some test suite failures. Need to revisit the KDC logging code after the merge.
* Tom: Looking at the client realm referral handling code.

Action items:
* Will: Commit current work to branch in MIT repository. Talk to Anup about extra resources.
* Ken: Fully committed for this week. Try to look at Will's branch next week. Review KDC logging again.

Coding style/Practices

2009-01-26T21:10:39Z

KenRaeburn: /* Misc. to be sorted */ we use small struct passing internally, have for a while; it's not a problem. omit -Wconversion

== String Handling ==

Code should not use any of the following functions: strcpy, strcat, sprintf, or any *scanf function.

Dynamically allocated buffers are preferred to fixed-sized buffers. When using dynamic buffers:
* Use strdup or asprintf for simple constructions.
* Use the k5buf module (k5-buf.h) for complex constructions. If this is not desirable, strlcpy and strlcat are valid alternatives.

Substitute versions of strlcpy, strlcat, and asprintf, for operating systems that don't supply them, are declared in k5-platform.h and defined in the support library (which practically everything in the tree links directly against).

When using fixed-sized buffers:
* Use strlcpy for simple copies.
* Use snprintf for simple compound constructions. Avoid using precision or field width specifiers in snprintf format strings.
* To check for truncation when using snprintf, use the following approach:
<pre>
result = snprintf(buffer, sizeof(buffer), "format string", ...);
if (SNPRINTF_OVERFLOW(result, sizeof(buffer))
handle_overflow_error;
</pre>
The SNPRINTF_OVERFLOW macro is defined in k5-platform.h.

=== Current conformance ===

Existing code mostly conforms, with some exceptions.

=== Rationale ===

It is relatively common to audit a code base such as krb5 and flag all uses of strcpy and similar functions, even if they are used safely. Verifying that the function is used safely requires manual inspection. Using safer alternatives does not guarantee code safety, but does reduce the likelihood of a catastrophic buffer overflow vulnerability.

In some compilation environments under Solaris, field widths and precisions are computed using screen columns rather than bytes.

sprintf returns a signed integer; buffer sizes are typically size_t (which is an unsigned type). Comparing the two directly will result in a warning from some compilers, and has unpredictable semantics depending on the relative widths of int and size_t. Also, some sprintf implementations, such as the one in Solaris prior to version 10, return -1 on a buffer overflow, whereas the C99 behavior returns the number of bytes which would have been written to the string. The SNPRINTF_OVERFLOW macro uses casts to address both issues.

The k5buf module safely allows multi-step string construction within fixed-size or dynamic buffers without performing an error check on each append, and without pre-computing lengths. Errors need only be checked when the resulting string needs to be read or handed off to another function.

== Exception Handling ==

If a function allocates several resources and has many exit paths, use the following general structure when possible:

<pre>
{
krb5_error_code retval;
char *ptr1 = NULL;
krb5_blah *ptr2 = NULL;

...
retval = another_function(...);
if (retval != 0)
goto cleanup;
...
cleanup:
if (ptr1)
free(ptr1);
if (ptr2)
kbr5_free_blah(ptr2);
return retval;
}
</pre>

Simpler functions may use simpler structures, but do not get to the point of freeing the same resource in several different places within a function depending on the exit path.

=== Current conformance ===

Existing code mostly conforms, with some exceptions.

=== Rationale ===

This is the most reliable way to avoid resource leaks within the constraints of the krb5 code base. Within libraries, the code base does not abort on memory allocation failure, so tends to have many exit paths within some functions.

== Output parameter handling ==

If a function has output parameters, it should initialize them in all cases, even if it returns failure. Most of the time, this means setting pointer output parameters to NULL and numeric output parameters to zero at the beginning of the function. The real output values should not be assigned to the output parameters until successful completion from the function is guaranteed. A typical function with output parameters should look something like:

<pre>
krb5_error_code
function_with_output_param(type *input_param, type *out_ptr, int *out_len)
{
declarations here;

*out_ptr = NULL;
*out_len = 0;

stuff that can go wrong here;

*out_ptr = ptr;
*out_len = len;
return 0;

error:
cleanup code here;
return ret;
}
</pre>

Simple wrappers do not need to worry about this rule unless they are invoking functions through pointers.

=== Current conformance ===

Existing code mostly does not conform.

=== Rationale ===

This practice makes it clear to static analysis tools that the previous value of the output parameter will not be used, and also helps convey under what circumstances an output parameter is initialized. If there happens to be a bug in the function such that it returns success but does not set output parameters, or in the caller such that it uses an output parameter even though the function returned failure, then the bug will result in predictable behavior (generally a NULL pointer dereference) with no security consequences beyond a denial of service attack.

== Assignments as truth values ==

Do not use assignments as truth values. Rather than this:

<pre>
/* bad style */
if ((retval = krb5_foo()))
/* ... */;
</pre>

do this:

<pre>
/* better style */
retval = krb5_foo();
if (retval)
/* ... */;
</pre>

=== Current conformance ===

Existing code varies widely.

=== Rationale ===

This makes the code easier to read, and also makes it easier to use
debuggers. It may be excusable to put assignments into the
conditional espression of a "while" statement, though, like:

<pre>
while ((ch = getopt(argc, argv, "abn")) != -1)
/* ... */;
</pre>

Using assignments as truth values in conditional expressions ("ternary expressions") may make
code particularly impenetrable.

== The many names of zero ==

There are at least three types of "zero" known to C. These are the
integer zero (0), the null pointer constant (NULL), and the character
constant zero ('\0'). Yes, these are usually all technically the
integer zero. Use them in their correct contexts. (Purists will
point out that 0 is a valid null pointer constant; still, do not use 0
to specify a null pointer constant. For further unconfusion, read the
section on null pointer constants in the C FAQ.) Do not use a lone
variable as a truth value unless it's of integer type. Thus:

<pre>
int i;
char *cp;
/* ... */
if (i)
/* ... */;
if (cp != NULL) {
while (*cp != '\0')
/* ... */;
}
</pre>

Do not cast uses of NULL unless you're calling a function with a
variable number of arguments, in which case you should cast it to to
the appropriate pointer type. (NULL may be defined as 0, and an integer 0
may not be the same size in the argument list as a pointer on a 64-bit
platform.) Likewise, do not cast the return value
from malloc() and friends; the prototype should declare them properly
as returning a void * and thus shouldn't require an explicit cast.

In any case, reading the section in the C FAQ on null pointers is
highly recommended to remove confusion regarding null pointers in C,
since this is a subject of much confusion to even experienced
programmers. In particular, if you do not understand why using
calloc() to allocate a struct that contains pointer members or why
calling memset() to initialize such a struct to all-bytes-zero is
wrong, reread that section again. (Note that there are *lots* of
examples of code in the krb5 source tree that erroneously calls
memset() to zero a struct, and we should fix these somehow
eventually.)

== Brace placement ==

Control flow statements that have a single statement as their body
should nevertheless have braces around their bodies if the body is
more than one line long, especially in the case of stacked multiple
if-else clauses; use:

<pre>
if (x) {
if (y)
foo();
else
bar();
}
</pre>

instead of:

<pre>
/* bad style */
if (x)
if (y)
foo();
else
bar();
</pre>

which, while legible to the compiler, may confuse human readers and
make the code less maintainable, especially if new branches get added
to any of the clauses.

If you are writing a do-while loop that has only one statement in its
body, put braces around it anyway, since the while clause may be
mistaken for a while loop with an empty body. Don't do this:

<pre>
/* bad style */
do
foo();
while (x);
</pre>

Instead, write this:

<pre>
/* better style */
do {
foo();
} while (x);
</pre>

== Preprocessor conditionals ==

Instead of scattering <code>#ifdef</code> or other preprocessor conditionals throughout the code use preprocessor conditionals to control the definition of a function-like macro, or similar construct, which is used instead of embedded preprocessor conditionals in code.

Instead of this:

<pre>
do_something();
/* bad style */
#ifdef DEBUG
fprintf(stderr, "did something\n");
#endif
do_something_else();
</pre>

do something more like this:

<pre>
#ifdef DEBUG
#define DPRINTF(x) fprintf(stderr, x)
#else
#define DPRINTF(x) /* empty */
#endif

/* ... */

do_something();
/* better style */
DPRINTF(("did something\n"));
do_something_else();
</pre>

Do not intersperse conditional compilation
directives with control flow statements, as some combination of
<code>#define</code>d symbols may result in statements getting eaten by dangling
bits of control flow statements. When it is not possible to avoid
this questionable practice (you really should rewrite the relevant
code section), make use of redundant braces to ensure that a compiler
error will result in preference to incorrect runtime behavior (such as
inadvertently providing someone with a root shell).

Do not intersperse conditional compilation directives with control
flow statements in such a way that confuses emacs cc-mode. Not only
does emacs get confused, but the code becomes more difficult to read
and maintain. Therefore, avoid code like this:

<pre>
/* bad style */
if (x) {
f();
}
#ifdef FOO
else if (y) {
#else
else {
#endif
g();
}
</pre>

Put comments after conditional compilation directives such as "#else"
and "#endif". Make them correspond to the sense of the value that
controls the compilation of the section they are closing, i.e.

<pre>
#ifdef FOO
/* ... */
#else /* !FOO */
/* ... */
#endif /* !FOO */
</pre>

Also, in the case of more complex conditional compilation directives,
write the comments like this:

<pre>
#if defined(FOO) || defined(BAR)
/* ... */
#else /* !(defined(FOO) || defined(BAR)) */
/* ... */
#endif /* !(defined(FOO) || defined(BAR)) */
</pre>

=== Conformance ===

Existing code mostly does not conform.

=== Rationale ===

Instances of "ifdef soup" make code more difficult to read, and make it more difficult to recognize bugs.

== Local variables ==

Do not declare variables in an inner scope, e.g. inside the compound
substatement of an if statement, unless the complexity of the code
really demands that the variables be declared that way. In such
situations, the function could probably stand to be broken up into
smaller chunks anyway. Do not declare variables in an inner scope
that shadow ones in an outer scope, since this leads to confusion.
Also, some debugging environments, such as gdb under Solaris, can't
see variables declared in an inner scope, so declaring such variables
will make maintenance more difficult as well.

== Placement of parentheses ==

Parenthesize expressions that may be confusing, particularly where C's
precedences are broken. For example, the shift operators have lower
precedence than the +, -, *, /, and % operators. Perhaps the most
familiar C precedence quirk is that equality and relational operators
are of higher precedence than assignment operators. Less well known
is that the bitwise operators are of a lower precedence than equality
and relational operators.

The sizeof operator takes either a unary expression or a parenthesized
type name. It is not necessary to parenthesize the operand of sizeof
if it is applied to a unary expression, but still, always parenthesize
the operand of the sizeof operator. The sizeof operator does not
evaluate its operand if it is a unary expression, so usages such as

<pre>
s = sizeof(++foo);
</pre>

should be avoided for the sake of sanity and readability.

== Function-like macros ==

Macros should have all-uppercase names. If it is necessary to use
multiple statements, use braces, and wrap the whole thing in a
do-while(0) construct, such as

<pre>
#define FOOMACRO(x, y) do { \
foo = (x) + (y); \
f(y); \
} while (0)
</pre>

Leave off the semicolon at the end of a function-like macro, so that
it can be mostly used like a call to a function without a return
value. Line up the backslashes to make it more readable. Use M-x
c-backslash-region in emacs to do neat lined-up backslashes.
Parenthesize uses of arguments in the replacement text of a macro in
order to prevent weird interactions.

== Namespaces ==

The C standard reserves a bunch of namespaces for the implementation.
Don't stomp on them. For practical purposes, any identifier with a
leading underscore should not be used. (Technically, ^_[a-z].* are
reserved only for file scope, so should be safe for things smaller
than file scope, but it's better to be paranoid in this case.)

POSIX reserves typedef names ending with _t as well.

Recall that errno is a reserved identifier, and is permitted to be a
macro. Therefore, do not use errno as the name of a structure member,
etc.

Reserved namespaces are somewhat more restricted than this; read the
appropriate section of the C standard if you have questions.

If you're writing new library code, pick a short prefix and stick with
it for any identifier with external linkage. If for some reason a
library needs to have external symbols that should not be visible to
the application, pick another (related) prefix to use for the internal
globals. This applies to typedef names, tag names, and preprocessor
identifiers as well.

For the krb5 library, the prefix for public global symbols is "krb5_".
Use "krb5int_" as a prefix for library internal globals. Avoid using
"__" in symbol names, as it may confuse C++ implementations. There
are admittedly a number of places where we leak thing into the
namespace; we should try to fix these.

Header files should also not leak symbols. Usually using the upcased
version of the prefix you've picked will suffice, e.g. "KRB5_" as a
CPP symbol prefix corresponding to "krb5_". In general, do not define
macros that are lowercase, in order to avoid confusion and to prevent
namespace collisions.

The C standard only guarantees six case-insensitive characters to be
significant in external identifiers; this is largely regarded as
obsolescent even in 1989 and we will ignore it. It does, however,
only guarantee 31 case-sensitive characters to be signficant in
internal identifiers, so do not use identifiers that differ beyond the
31st character. This is unlikely to be a problem, though.

== Misc. to be sorted ==

Assume, for most purposes, working ANSI/ISO C ('89, not '99) support,
both for internal use and for applications compiling against Kerberos
header files and libraries. Some exceptions are noted below.

While it is syntactically correct to call through a function pointer
without applying a dereference operator to it, do not write code that
does this. It is easier to see that the function call is actually
taking place through a function pointer if you write an explicit
dereference. However, do not explicitly take the address of a
function in order to assign it to a function pointer, since a function
name degrades into a pointer. Thus:

<pre>
int (*fp)(void);
int foofunc(void);
fp = foofunc;
x = (*fp)();
</pre>

In general, do not take the address of an array. It does not return a
pointer to the first element; it returns a pointer to the array
itself. These are often identical when cast to an integral type, but
they are inherently of different types themselves. Functions that
take array types or pointers to array types as arguments can be
particularly trouble-prone.

If a function is declared to return a value, do not call "return"
without an argument or allow the flow of control to fall off the end
of the function.

Always declare the return type of a function, even if it returns int.
Yes, this means declaring main() to return int, since main() is
required to return int by the standard. If a function is not supposed
to return a value, declare it as returning void rather than omitting
the return type, which will default the return type to int.

Try to use ANSI C prototype-style function definitions in preference
to K&R style definitions. When using K&R style function definitions,
declare all the argument types, even those that are int, but beware of
any narrow types in the argument list.

Don't pass or return structures in API functions except by address.

For new functions, input parameters should go before output parameters
in the call signature. There are exceptions, such as a context-like
parameter.

Every function should have block comment preceding it describing
briefly in complete sentences what it does, what inputs and outputs it
has, and what error codes it can return. It should also describe any
unusual aspects of the function. At some point we will want to put
some of this information into a machine-parsable form.

Strive to make your code capable of compiling using "gcc -Wall
-Wmissing-prototypes -Wtraditional -Wcast-qual -Wcast-align
-pedantic" [XXX need to rethink this
somewhat] without generating any errors or warnings. Do not, however,
compile using the "-ansi" flag to gcc, since that can result in odd
behavior with header files on some systems, causing some necessary
symbols to not be defined.

Coding style/Practices

2009-01-26T19:21:16Z

KenRaeburn: /* The many names of zero */

== String Handling ==

Code should not use any of the following functions: strcpy, strcat, sprintf, or any *scanf function.

Dynamically allocated buffers are preferred to fixed-sized buffers. When using dynamic buffers:
* Use strdup or asprintf for simple constructions.
* Use the k5buf module (k5-buf.h) for complex constructions. If this is not desirable, strlcpy and strlcat are valid alternatives.

Substitute versions of strlcpy, strlcat, and asprintf, for operating systems that don't supply them, are declared in k5-platform.h and defined in the support library (which practically everything in the tree links directly against).

When using fixed-sized buffers:
* Use strlcpy for simple copies.
* Use snprintf for simple compound constructions. Avoid using precision or field width specifiers in snprintf format strings.
* To check for truncation when using snprintf, use the following approach:
<pre>
result = snprintf(buffer, sizeof(buffer), "format string", ...);
if (SNPRINTF_OVERFLOW(result, sizeof(buffer))
handle_overflow_error;
</pre>
The SNPRINTF_OVERFLOW macro is defined in k5-platform.h.

=== Current conformance ===

Existing code mostly conforms, with some exceptions.

=== Rationale ===

It is relatively common to audit a code base such as krb5 and flag all uses of strcpy and similar functions, even if they are used safely. Verifying that the function is used safely requires manual inspection. Using safer alternatives does not guarantee code safety, but does reduce the likelihood of a catastrophic buffer overflow vulnerability.

In some compilation environments under Solaris, field widths and precisions are computed using screen columns rather than bytes.

sprintf returns a signed integer; buffer sizes are typically size_t (which is an unsigned type). Comparing the two directly will result in a warning from some compilers, and has unpredictable semantics depending on the relative widths of int and size_t. Also, some sprintf implementations, such as the one in Solaris prior to version 10, return -1 on a buffer overflow, whereas the C99 behavior returns the number of bytes which would have been written to the string. The SNPRINTF_OVERFLOW macro uses casts to address both issues.

The k5buf module safely allows multi-step string construction within fixed-size or dynamic buffers without performing an error check on each append, and without pre-computing lengths. Errors need only be checked when the resulting string needs to be read or handed off to another function.

== Exception Handling ==

If a function allocates several resources and has many exit paths, use the following general structure when possible:

<pre>
{
krb5_error_code retval;
char *ptr1 = NULL;
krb5_blah *ptr2 = NULL;

...
retval = another_function(...);
if (retval != 0)
goto cleanup;
...
cleanup:
if (ptr1)
free(ptr1);
if (ptr2)
kbr5_free_blah(ptr2);
return retval;
}
</pre>

Simpler functions may use simpler structures, but do not get to the point of freeing the same resource in several different places within a function depending on the exit path.

=== Current conformance ===

Existing code mostly conforms, with some exceptions.

=== Rationale ===

This is the most reliable way to avoid resource leaks within the constraints of the krb5 code base. Within libraries, the code base does not abort on memory allocation failure, so tends to have many exit paths within some functions.

== Output parameter handling ==

If a function has output parameters, it should initialize them in all cases, even if it returns failure. Most of the time, this means setting pointer output parameters to NULL and numeric output parameters to zero at the beginning of the function. The real output values should not be assigned to the output parameters until successful completion from the function is guaranteed. A typical function with output parameters should look something like:

<pre>
krb5_error_code
function_with_output_param(type *input_param, type *out_ptr, int *out_len)
{
declarations here;

*out_ptr = NULL;
*out_len = 0;

stuff that can go wrong here;

*out_ptr = ptr;
*out_len = len;
return 0;

error:
cleanup code here;
return ret;
}
</pre>

Simple wrappers do not need to worry about this rule unless they are invoking functions through pointers.

=== Current conformance ===

Existing code mostly does not conform.

=== Rationale ===

This practice makes it clear to static analysis tools that the previous value of the output parameter will not be used, and also helps convey under what circumstances an output parameter is initialized. If there happens to be a bug in the function such that it returns success but does not set output parameters, or in the caller such that it uses an output parameter even though the function returned failure, then the bug will result in predictable behavior (generally a NULL pointer dereference) with no security consequences beyond a denial of service attack.

== Assignments as truth values ==

Do not use assignments as truth values. Rather than this:

<pre>
/* bad style */
if ((retval = krb5_foo()))
/* ... */;
</pre>

do this:

<pre>
/* better style */
retval = krb5_foo();
if (retval)
/* ... */;
</pre>

=== Current conformance ===

Existing code varies widely.

=== Rationale ===

This makes the code easier to read, and also makes it easier to use
debuggers. It may be excusable to put assignments into the
conditional espression of a "while" statement, though, like:

<pre>
while ((ch = getopt(argc, argv, "abn")) != -1)
/* ... */;
</pre>

Using assignments as truth values in conditional expressions ("ternary expressions") may make
code particularly impenetrable.

== The many names of zero ==

There are at least three types of "zero" known to C. These are the
integer zero (0), the null pointer constant (NULL), and the character
constant zero ('\0'). Yes, these are usually all technically the
integer zero. Use them in their correct contexts. (Purists will
point out that 0 is a valid null pointer constant; still, do not use 0
to specify a null pointer constant. For further unconfusion, read the
section on null pointer constants in the C FAQ.) Do not use a lone
variable as a truth value unless it's of integer type. Thus:

<pre>
int i;
char *cp;
/* ... */
if (i)
/* ... */;
if (cp != NULL) {
while (*cp != '\0')
/* ... */;
}
</pre>

Do not cast uses of NULL unless you're calling a function with a
variable number of arguments, in which case you should cast it to to
the appropriate pointer type. (NULL may be defined as 0, and an integer 0
may not be the same size in the argument list as a pointer on a 64-bit
platform.) Likewise, do not cast the return value
from malloc() and friends; the prototype should declare them properly
as returning a void * and thus shouldn't require an explicit cast.

In any case, reading the section in the C FAQ on null pointers is
highly recommended to remove confusion regarding null pointers in C,
since this is a subject of much confusion to even experienced
programmers. In particular, if you do not understand why using
calloc() to allocate a struct that contains pointer members or why
calling memset() to initialize such a struct to all-bytes-zero is
wrong, reread that section again. (Note that there are *lots* of
examples of code in the krb5 source tree that erroneously calls
memset() to zero a struct, and we should fix these somehow
eventually.)

== Brace placement ==

Control flow statements that have a single statement as their body
should nevertheless have braces around their bodies if the body is
more than one line long, especially in the case of stacked multiple
if-else clauses; use:

<pre>
if (x) {
if (y)
foo();
else
bar();
}
</pre>

instead of:

<pre>
/* bad style */
if (x)
if (y)
foo();
else
bar();
</pre>

which, while legible to the compiler, may confuse human readers and
make the code less maintainable, especially if new branches get added
to any of the clauses.

If you are writing a do-while loop that has only one statement in its
body, put braces around it anyway, since the while clause may be
mistaken for a while loop with an empty body. Don't do this:

<pre>
/* bad style */
do
foo();
while (x);
</pre>

Instead, write this:

<pre>
/* better style */
do {
foo();
} while (x);
</pre>

== Preprocessor conditionals ==

Instead of scattering <code>#ifdef</code> or other preprocessor conditionals throughout the code use preprocessor conditionals to control the definition of a function-like macro, or similar construct, which is used instead of embedded preprocessor conditionals in code.

Instead of this:

<pre>
do_something();
/* bad style */
#ifdef DEBUG
fprintf(stderr, "did something\n");
#endif
do_something_else();
</pre>

do something more like this:

<pre>
#ifdef DEBUG
#define DPRINTF(x) fprintf(stderr, x)
#else
#define DPRINTF(x) /* empty */
#endif

/* ... */

do_something();
/* better style */
DPRINTF(("did something\n"));
do_something_else();
</pre>

Do not intersperse conditional compilation
directives with control flow statements, as some combination of
<code>#define</code>d symbols may result in statements getting eaten by dangling
bits of control flow statements. When it is not possible to avoid
this questionable practice (you really should rewrite the relevant
code section), make use of redundant braces to ensure that a compiler
error will result in preference to incorrect runtime behavior (such as
inadvertently providing someone with a root shell).

Do not intersperse conditional compilation directives with control
flow statements in such a way that confuses emacs cc-mode. Not only
does emacs get confused, but the code becomes more difficult to read
and maintain. Therefore, avoid code like this:

<pre>
/* bad style */
if (x) {
f();
}
#ifdef FOO
else if (y) {
#else
else {
#endif
g();
}
</pre>

Put comments after conditional compilation directives such as "#else"
and "#endif". Make them correspond to the sense of the value that
controls the compilation of the section they are closing, i.e.

<pre>
#ifdef FOO
/* ... */
#else /* !FOO */
/* ... */
#endif /* !FOO */
</pre>

Also, in the case of more complex conditional compilation directives,
write the comments like this:

<pre>
#if defined(FOO) || defined(BAR)
/* ... */
#else /* !(defined(FOO) || defined(BAR)) */
/* ... */
#endif /* !(defined(FOO) || defined(BAR)) */
</pre>

=== Conformance ===

Existing code mostly does not conform.

=== Rationale ===

Instances of "ifdef soup" make code more difficult to read, and make it more difficult to recognize bugs.

== Local variables ==

Do not declare variables in an inner scope, e.g. inside the compound
substatement of an if statement, unless the complexity of the code
really demands that the variables be declared that way. In such
situations, the function could probably stand to be broken up into
smaller chunks anyway. Do not declare variables in an inner scope
that shadow ones in an outer scope, since this leads to confusion.
Also, some debugging environments, such as gdb under Solaris, can't
see variables declared in an inner scope, so declaring such variables
will make maintenance more difficult as well.

== Placement of parentheses ==

Parenthesize expressions that may be confusing, particularly where C's
precedences are broken. For example, the shift operators have lower
precedence than the +, -, *, /, and % operators. Perhaps the most
familiar C precedence quirk is that equality and relational operators
are of higher precedence than assignment operators. Less well known
is that the bitwise operators are of a lower precedence than equality
and relational operators.

The sizeof operator takes either a unary expression or a parenthesized
type name. It is not necessary to parenthesize the operand of sizeof
if it is applied to a unary expression, but still, always parenthesize
the operand of the sizeof operator. The sizeof operator does not
evaluate its operand if it is a unary expression, so usages such as

<pre>
s = sizeof(++foo);
</pre>

should be avoided for the sake of sanity and readability.

== Function-like macros ==

Macros should have all-uppercase names. If it is necessary to use
multiple statements, use braces, and wrap the whole thing in a
do-while(0) construct, such as

<pre>
#define FOOMACRO(x, y) do { \
foo = (x) + (y); \
f(y); \
} while (0)
</pre>

Leave off the semicolon at the end of a function-like macro, so that
it can be mostly used like a call to a function without a return
value. Line up the backslashes to make it more readable. Use M-x
c-backslash-region in emacs to do neat lined-up backslashes.
Parenthesize uses of arguments in the replacement text of a macro in
order to prevent weird interactions.

== Namespaces ==

The C standard reserves a bunch of namespaces for the implementation.
Don't stomp on them. For practical purposes, any identifier with a
leading underscore should not be used. (Technically, ^_[a-z].* are
reserved only for file scope, so should be safe for things smaller
than file scope, but it's better to be paranoid in this case.)

POSIX reserves typedef names ending with _t as well.

Recall that errno is a reserved identifier, and is permitted to be a
macro. Therefore, do not use errno as the name of a structure member,
etc.

Reserved namespaces are somewhat more restricted than this; read the
appropriate section of the C standard if you have questions.

If you're writing new library code, pick a short prefix and stick with
it for any identifier with external linkage. If for some reason a
library needs to have external symbols that should not be visible to
the application, pick another (related) prefix to use for the internal
globals. This applies to typedef names, tag names, and preprocessor
identifiers as well.

For the krb5 library, the prefix for public global symbols is "krb5_".
Use "krb5int_" as a prefix for library internal globals. Avoid using
"__" in symbol names, as it may confuse C++ implementations. There
are admittedly a number of places where we leak thing into the
namespace; we should try to fix these.

Header files should also not leak symbols. Usually using the upcased
version of the prefix you've picked will suffice, e.g. "KRB5_" as a
CPP symbol prefix corresponding to "krb5_". In general, do not define
macros that are lowercase, in order to avoid confusion and to prevent
namespace collisions.

The C standard only guarantees six case-insensitive characters to be
significant in external identifiers; this is largely regarded as
obsolescent even in 1989 and we will ignore it. It does, however,
only guarantee 31 case-sensitive characters to be signficant in
internal identifiers, so do not use identifiers that differ beyond the
31st character. This is unlikely to be a problem, though.

== Misc. to be sorted ==

Assume, for most purposes, working ANSI/ISO C ('89, not '99) support,
both for internal use and for applications compiling against Kerberos
header files and libraries. Some exceptions are noted below.

While it is syntactically correct to call through a function pointer
without applying a dereference operator to it, do not write code that
does this. It is easier to see that the function call is actually
taking place through a function pointer if you write an explicit
dereference. However, do not explicitly take the address of a
function in order to assign it to a function pointer, since a function
name degrades into a pointer. Thus:

<pre>
int (*fp)(void);
int foofunc(void);
fp = foofunc;
x = (*fp)();
</pre>

In general, do not take the address of an array. It does not return a
pointer to the first element; it returns a pointer to the array
itself. These are often identical when cast to an integral type, but
they are inherently of different types themselves. Functions that
take array types or pointers to array types as arguments can be
particularly trouble-prone.

If a function is declared to return a value, do not call "return"
without an argument or allow the flow of control to fall off the end
of the function.

Always declare the return type of a function, even if it returns int.
Yes, this means declaring main() to return int, since main() is
required to return int by the standard. If a function is not supposed
to return a value, declare it as returning void rather than omitting
the return type, which will default the return type to int.

Try to use ANSI C prototype-style function definitions in preference
to K&R style definitions. When using K&R style function definitions,
declare all the argument types, even those that are int, but beware of
any narrow types in the argument list.

Don't pass around structures except by address. We may relax this
restriction for non-API functions, though.

For new functions, input parameters should go before output parameters
in the call signature. There are exceptions, such as a context-like
parameter.

Every function should have block comment preceding it describing
briefly in complete sentences what it does, what inputs and outputs it
has, and what error codes it can return. It should also describe any
unusual aspects of the function. At some point we will want to put
some of this information into a machine-parsable form.

Strive to make your code capable of compiling using "gcc -Wall
-Wmissing-prototypes -Wtraditional -Wcast-qual -Wcast-align
-Wconversion -Waggregate-return -pedantic" [XXX need to rethink this
somewhat] without generating any errors or warnings. Do not, however,
compile using the "-ansi" flag to gcc, since that can result in odd
behavior with header files on some systems, causing some necessary
symbols to not be defined.

Projects/Master Key Migration

2009-01-23T23:13:50Z

KenRaeburn: /* Design of implementation */ speling

{{project-approved}}

==Desired changes==

This project will provide the ability to add a new master key (with an
enctype differing from the current master key) to the master key
principal and stash file and then migrate the encryption of existing
principals long term keys to use the new master key. In addition
deletion of master keys will be provided.

==Functional Requirements==

The KDC must be able to deal with multiple master keys and determine
which key to use when decrypting a principal's long term secret key.
The KDC must be able to access any of the master key (K/M) principal's
keys as long as it has access to a master key that is in use.

The administrator must be able re-encrypt principal keys using a
specified mkey and be able to specifying the set of principals is to be
re-encrypted. The command doing this must be able to determine if a
principal's keys are protected by the current master key or not. This
implies that some set of principals may be protected with a non-current
master key.

Slave KDC's must be able to access all master keys currently protecting
principal entries and therefore have access to the principal's secret
keys regardless of which master key is used to encrypt the key.

The administrator will be able to:

* Add a new master key to master key principal and optionally to the masterkey keytab stash.

* Enable a new master key (make it the current master key used to protect newly created principals or principal rekeys).

* List all master keys associated with the master key principal.

* Delete a particular master key from the master key principal and optionally from the masterkey keytab stash.

* Purge unused master keys (keys not used to protect any principal).

==Design of implementation==

Fundamentally the current implementation must be changed to support
multiple master keys. And possession of any master key stored with the
K/M principal allows access to all master keys. In addition, a
principal's secret key may be encrypted by any of the master keys in use
and the KDC must be able to decrypt that principal's key.

In order to accommodate this, these changes will be made:

* A new TL-data type, KRB5_TL_MKVNO, would apply to all principals except the K/M and would store the version number of the master key used to encrypt the keys of that principal. The db2 back end would store it as opaque TL-data, the LDAP back end has a slot for it.
* A new TL-data type, KRB5_TL_ACTKVNO, would apply to all principals and will be a set of {actkvno, start_time} tuples where actkvno is the "active" KVNO and start_time indicates when actkvno is valid for use.
** When set for the K/M principal this indicates the master key to be used when encrypting principal's long term keys. If this TL-data type is not found in the K/M record then the default value for this will be 1 which is the default MKVNO.
** When set for service principals this indicates the key to be used when the KDC issues service tickets.
** Trailing stuff is ignored for now, making the structure extensible.
* The krb5_key_data array in the krb5_db_entry for the K/M principal will hold all master keys in use. All the keys in this array will be encrypted using the most recently created master key.
* A new TL-data type, KRB5_TL_MKEY_AUX, would apply only to the K/M principal. This new TL data would contain:
** A set of copies of the latest master key, each encrypted by one of the other supported mkeys, in {old-mkvno, keydata} tuples. Thus the "master key" used in DAL (DB abstraction layer) need only be any one of these keys.
** Trailing stuff is ignored for now, making the structure extensible.
* kdc_realm_t will be modified to hold all master keys (including KVNO and enctype) associated with a realm. It will also hold the current mkey KVNO that should be used when encrypting a principal's keys. To facilitate this, a new struct will be defined:

typedef struct _krb5_keylist_node {
krb5_keyblock *keyblock;
krb5_kvno kvno;
struct _krb5_keylist_node *next;
} krb5_keyblock_node;

This will be used to create a list of mkeys. kdc_realm_t will also have
a current_realm_mkey which will point to the krb5_keyblock_node that
contains the current mkey (used when encrypting a principal's keys, does
not apply the K/M mkeys).

The initialization of the list of mkeys will occur in init_realm().

Any code needing to decrypt principal keys will need to determine which
mkey to use. A function will be created to return the mkey to use for
decrypting a principal's keys given the principal's krb5_db_entry and
realm_mkeys list as input args. If the principals krb5_db_entry does
not contain KRB5_TL_MKVNO TL-data the function will default to choosing
the mkey with KVNO 1. If the princ krb5_db_entry does have
KRB5_TL_MKVNO data and no matching mkey is found the function will get
the K/M princ KDB entry, update the list of mkeys if new mkeys are found
and return a matching mkey if found. An error will be returned if a
matching mkey is not found.

This function would be called prior to calling
krb5_dbekd_decrypt_key_data() to determine which mkey to pass in.

Similarly, any code calling krb5_dbekd_encrypt_key_data() will be
modified to pass in the current_realm_mkey (mentioned above).

kdb5_util will be modified to support these new commands:

; add_mkey [-s] : Add a new master key to K/M. The optional -s will add the mkey to the stash file.

; use_mkey <KVNO> [startdate] : Set the current mkey KVNO. This controls which master key is used when encrypting principal keys. The kadmind and krb5kdc should be restarted after this command successfully completes.

; list_mkeys : Shows all master keys from most recent to earliest in K/M principal. The output will show the KVNO, enctype and salt for each mkey similar to kadmin getprinc output. A * following an mkey denotes the current mkey.

; purge_mkeys [-f] : Delete mkeys from K/M princ that are not used to protect any principals. With -f, does not prompt user. The prompt will be "Delete version 3 master key for the FOO.COM realm? [y/n] ".

; sync_stash [-f] : Sync up the set of keys in the keytab stash with those in the K/M princ entry in the KDB. Keys in keytab stash not found in K/M will be removed. With -f, does not prompt user.

; update_princ_encryption [-f] [expression] : Use current mkey to encrypt principals (other than K/M) secret keys if not already encrypted by that mkey. Should support either doing all princs if no argument given or a subset specified by expression (supports shell-style globbing, similar to kadmin). Both the principal's secret keys and key history will first be decrypted with the original encrypting mkey then encrypted with the current mkey. If the current mkey kvno is that of the mkey that originally encrypted the principal's keys the code will stop processing that principal and go on to the next. With -f, does not prompt user.

The kdb5_util dump -mkey_convert will be modified to update the
KRB5_TL_MKVNO of all principals except the K/M principal with the KVNO
of the mkey used for the conversion. The K/M KRB5_TL_MKEY_AUX TL data
will be updated to include the new mkey used for the conversion.

==Tasks/milestones==

* project start. Aug 29, 2008
* project review. ~2 week
* Implementation. ~6 weeks
* test. ~4 week
* code review. ~2 week
* documentation. ~3 day

==Desired integration and release goals==

==Testing plan==

Unit testing of all new and modified commands will be done to verify
they work as specified. This will be done for both the db2 and LDAP KDB
plugins. Unit tests will include testing that the various of setting a
new key (kpasswd, kadmin commands like cpw or ktadd, as well as the
new/modified commands) when applied to the master key principal will
either be rejected without changing the database or retain all the old
keys, even if that list is larger than the normal key history size in
order to make sure the normal key history mechanisms won't accidentally
throw away any still-used master keys.

The kadmind and krb5kdc daemons will be tested to verify they work
properly when accessing a KDB some set of principals is protected by one
mkey and the other set is protected by another set. Slave KDCs will
also be tested after the KDB is propagated both with kprop and kiprop.

Bounds testing will verify the krb utils and daemons work properly when
the MKVNO wraps back to 1 (0 is not a valid value).

The existing MIT Kerberos test suites will be run to make sure there are
no regressions introduced by this project.

==Review==

This section documents the review of the project according to [[Project policy]].
It is divided into multiple sections. First, approvals should be listed. To list an approval type
:<nowiki>#~~~~</nowiki>
on its own line.
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with
:<nowiki>--~~~~</nowiki>
and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.

===Approvals===

#[[User:TomYu|TomYu]]

===Discussion===

== Current status ==

Coding style

2009-01-08T16:49:46Z

KenRaeburn: /* Emacs cc-mode style */ rephrase last change - update isn't automatic, you get prompted

__NOTOC__
The C language '''Coding style''' described here is based on the BSD coding style, with some additional elements from the GNU coding standards and the SunOS coding standards.

* [[Coding style/Formatting|Formatting]]
* [[Coding style/Practices|Practices]]

== External links ==

* [http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/share/misc/style?rev=HEAD NetBSD <code>/usr/share/misc/style</code>] [http://cvsweb.netbsd.org/bsdweb.cgi/src/share/misc/style (log)]
* [http://www.gnu.org/prep/standards/ GNU coding standards]
* [http://opensolaris.org/os/community/documentation/getting_started_docs/cstyle.ms.pdf C Style and Coding Standards for SunOS]

== Old version ==

Old content to be moved elsewhere is below.

----

== WRITING C CODE ==

The code in the krb5 source tree largely follows BSD KNF
(/usr/share/misc/style on NetBSD) except that it uses a four column
basic offset. The style described here is a synthesis of BSD KNF and
the GNU coding standards for the C language. The formatting described
in the "Formatting Your Source Code" section of the GNU coding
standards is mostly what we want, except we use BSD brace style and
BSD-ish conventions for the spacing around operators.

=== Coding practices for C ===

=== Aspects of C style in GNU coding std but not here ===

* redundant parens to force extra indent of operators of different precedences

* redundant parens to force general extra indent of expressions that are broken between lines

* use of ^L characters to break up source files into pages

* nitpicking about capitalization in comments of variable names when their values are meant

* commenting usages of static variables

* casts to void

* separation of word in names with underscores vs case change

* enum vs #define'd integer constants

* 14 char filename limits, MS-DOS filename limits

* portability

* system library function quirks

* internationalization

* mmap()

=== Aspects of C style in BSD KNF but not here ===

* sorting of header files

* sorting of struct members

* separating struct tag decl and struct typedef

* sorting of var decl

* lining up var names in decls

* newline after decls

* usage of __P

* usage of getopt

* not initializing vars in decls

* stdarg/varargs handling

=== Emacs cc-mode style ===

Putting the following code in your .emacs file will result in mostly
the right thing happening with respect to formatting style. Note that
you may want to turn on auto-newline feature of cc-mode, though that
seems to have some bugs with brace-elseif-brace handling at least in
the version of cc-mode that comes with emacs 20.3.

(defconst krb5-c-style
'("bsd"
(c-cleanup-list
brace-elseif-brace brace-else-brace defun-close-semi)
(c-comment-continuation-stars . "* ")
(c-electric-pound-behavior alignleft)
(c-hanging-braces-alist
(brace-list-open)
(class-open after)
(substatement-open after)
(block-close . c-snug-do-while)
(extern-lang-open after))
(c-hanging-colons-alist
(case-label after)
(label after))
(c-hanging-comment-starter-p)
(c-hanging-comment-ender-p)
(c-indent-comments-syntactically-p . t)
(c-label-minimum-indentation . 0)
(c-special-indent-hook)))
(defun krb5-c-hook ()
(c-add-style "krb5" krb5-c-style t))
(add-hook 'c-mode-common-hook 'krb5-c-hook)

You might also want to try (for Emacs 22 and later):

(add-hook 'before-save-hook 'copyright-update)

which will offer to update the year in the top-most copyright notice in a file when you save it, if it's not already current.

=== indent.pro settings ===

The following settings for the indent program should produce a
reasonable approximation to the C coding style described here, though
some manual cleanup may be necessary. Note that the gindent installed
in the gnu locker does not currently handle -psl correctly though.

<pre>
-bap
-br
-ce
-ci4
-cli0
-d0
-di8
-i4
-ip4
-l79
-nbc
-ncdb
-ndj
-nfc1
-lp
-npcs
-psl
-sc
-sob
</pre>

Coding style

2009-01-08T00:58:08Z

KenRaeburn: /* Emacs cc-mode style */ suggest copyright-update hook

__NOTOC__
The C language '''Coding style''' described here is based on the BSD coding style, with some additional elements from the GNU coding standards and the SunOS coding standards.

* [[Coding style/Formatting|Formatting]]
* [[Coding style/Practices|Practices]]

== External links ==

* [http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/share/misc/style?rev=HEAD NetBSD <code>/usr/share/misc/style</code>] [http://cvsweb.netbsd.org/bsdweb.cgi/src/share/misc/style (log)]
* [http://www.gnu.org/prep/standards/ GNU coding standards]
* [http://opensolaris.org/os/community/documentation/getting_started_docs/cstyle.ms.pdf C Style and Coding Standards for SunOS]

== Old version ==

Old content to be moved elsewhere is below.

----

== WRITING C CODE ==

The code in the krb5 source tree largely follows BSD KNF
(/usr/share/misc/style on NetBSD) except that it uses a four column
basic offset. The style described here is a synthesis of BSD KNF and
the GNU coding standards for the C language. The formatting described
in the "Formatting Your Source Code" section of the GNU coding
standards is mostly what we want, except we use BSD brace style and
BSD-ish conventions for the spacing around operators.

=== Coding practices for C ===

=== Aspects of C style in GNU coding std but not here ===

* redundant parens to force extra indent of operators of different precedences

* redundant parens to force general extra indent of expressions that are broken between lines

* use of ^L characters to break up source files into pages

* nitpicking about capitalization in comments of variable names when their values are meant

* commenting usages of static variables

* casts to void

* separation of word in names with underscores vs case change

* enum vs #define'd integer constants

* 14 char filename limits, MS-DOS filename limits

* portability

* system library function quirks

* internationalization

* mmap()

=== Aspects of C style in BSD KNF but not here ===

* sorting of header files

* sorting of struct members

* separating struct tag decl and struct typedef

* sorting of var decl

* lining up var names in decls

* newline after decls

* usage of __P

* usage of getopt

* not initializing vars in decls

* stdarg/varargs handling

=== Emacs cc-mode style ===

Putting the following code in your .emacs file will result in mostly
the right thing happening with respect to formatting style. Note that
you may want to turn on auto-newline feature of cc-mode, though that
seems to have some bugs with brace-elseif-brace handling at least in
the version of cc-mode that comes with emacs 20.3.

(defconst krb5-c-style
'("bsd"
(c-cleanup-list
brace-elseif-brace brace-else-brace defun-close-semi)
(c-comment-continuation-stars . "* ")
(c-electric-pound-behavior alignleft)
(c-hanging-braces-alist
(brace-list-open)
(class-open after)
(substatement-open after)
(block-close . c-snug-do-while)
(extern-lang-open after))
(c-hanging-colons-alist
(case-label after)
(label after))
(c-hanging-comment-starter-p)
(c-hanging-comment-ender-p)
(c-indent-comments-syntactically-p . t)
(c-label-minimum-indentation . 0)
(c-special-indent-hook)))
(defun krb5-c-hook ()
(c-add-style "krb5" krb5-c-style t))
(add-hook 'c-mode-common-hook 'krb5-c-hook)

You might also want to try (for Emacs 22 and later):

(add-hook 'before-save-hook 'copyright-update)

to let you automatically update the year in the top-most copyright notice in a file when you save it.

=== indent.pro settings ===

The following settings for the indent program should produce a
reasonable approximation to the C coding style described here, though
some manual cleanup may be necessary. Note that the gindent installed
in the gnu locker does not currently handle -psl correctly though.

<pre>
-bap
-br
-ce
-ci4
-cli0
-d0
-di8
-i4
-ip4
-l79
-nbc
-ncdb
-ndj
-nfc1
-lp
-npcs
-psl
-sc
-sob
</pre>

Coding style/Practices

2009-01-08T00:51:30Z

KenRaeburn: /* String Handling */ remove dup; point out needed headers

== String Handling ==

Code should not use any of the following functions: strcpy, strcat, sprintf, or any *scanf function.

Dynamically allocated buffers are preferred to fixed-sized buffers. When using dynamic buffers:
* Use strdup or asprintf for simple constructions.
* Use the k5buf module (k5-buf.h) for complex constructions. If this is not desirable, strlcpy and strlcat are valid alternatives.

Substitute versions of strlcpy, strlcat, and asprintf, for operating systems that don't supply them, are declared in k5-platform.h and defined in the support library (which practically everything in the tree links directly against).

When using fixed-sized buffers:
* Use strlcpy for simple copies.
* Use snprintf for simple compound constructions. Avoid using precision or field width specifiers in snprintf format strings.
* To check for truncation when using snprintf, use the following approach:
<pre>
result = snprintf(buffer, sizeof(buffer), "format string", ...);
if (SNPRINTF_OVERFLOW(result, sizeof(buffer))
handle_overflow_error;
</pre>
The SNPRINTF_OVERFLOW macro is defined in k5-platform.h.

=== Current conformance ===

Existing code does not conform, but is under active conversion.

=== Rationale ===

It is relatively common to audit a code base such as krb5 and flag all uses of strcpy and similar functions, even if they are used safely. Verifying that the function is used safely requires manual inspection. Using safer alternatives does not guarantee code safety, but does reduce the likelihood of a catastrophic buffer overflow vulnerability.

In some compilation environments under Solaris, field widths and precisions are computed using screen columns rather than bytes.

sprintf returns a signed integer; buffer sizes are typically size_t (which is an unsigned type). Comparing the two directly will result in a warning from some compilers, and has unpredictable semantics depending on the relative widths of int and size_t. Also, some sprintf implementations, such as the one in Solaris prior to version 10, return -1 on a buffer overflow, whereas the C99 behavior returns the number of bytes which would have been written to the string. The SNPRINTF_OVERFLOW macro uses casts to address both issues.

The k5buf module safely allows multi-step string construction within fixed-size or dynamic buffers without performing an error check on each append, and without pre-computing lengths. Errors need only be checked when the resulting string needs to be read or handed off to another function.

== Exception Handling ==

If a function allocates several resources and has many exit paths, use the following general structure when possible:

<pre>
{
krb5_error_code retval;
char *ptr1 = NULL;
krb5_blah *ptr2 = NULL;

...
retval = another_function(...);
if (retval != 0)
goto cleanup;
...
cleanup:
if (ptr1)
free(ptr1);
if (ptr2)
kbr5_free_blah(ptr2);
return retval;
}
</pre>

Simpler functions may use simpler structures, but do not get to the point of freeing the same resource in several different places within a function depending on the exit path.

=== Current conformance ===

Existing code mostly conforms, with some exceptions.

=== Rationale ===

This is the most reliable way to avoid resource leaks within the constraints of the krb5 code base. Within libraries, the code base does not abort on memory allocation failure, so tends to have many exit paths within some functions.

== Assignments as truth values ==

Do not use assignments as truth values. Rather than this:

<pre>
/* bad style */
if ((retval = krb5_foo()))
/* ... */;
</pre>

do this:

<pre>
/* better style */
retval = krb5_foo();
if (retval)
/* ... */;
</pre>

This makes the code easier to read, and also makes it easier to use
debuggers. It may be excusable to put assignments into the
conditional espression of a "while" statement, though, like:

<pre>
while ((ch = getopt(argc, argv, "abn")) != -1)
/* ... */;
</pre>

Using assignments as truth values in conditional expressions may make
code particularly impenetrable.

== The many names of zero ==

There are at least three types of "zero" known to C. These are the
integer zero (0), the null pointer constant (NULL), and the character
constant zero ('\0'). Yes, these are usually all technically the
integer zero. Use them in their correct contexts. (Purists will
point out that 0 is a valid null pointer constant; still, do not use 0
to specify a null pointer constant. For further unconfusion, read the
section on null pointer constants in the C FAQ.) Do not use a lone
variable as a truth value unless it's of integer type. Thus:

<pre>
int i;
char *cp;
/* ... */
if (i)
/* ... */;
if (cp != NULL) {
while (*cp != '\0')
/* ... */;
}
</pre>

Do not cast uses of NULL unless you're calling a function with a
variable number of arguments, in which case you should cast it to to
the appropriate pointer type. Likewise, do not cast the return value
from malloc() and friends; the prototype should declare them properly
as returning a void * and thus shouldn't require an explicit cast.

Do not assume that realloc(NULL, size) will do the right thing, or
that free(NULL) will do the right thing. ANSI guarantees that it
will, but some old libraries (hopefully becoming obsolete) don't.
Also, don't assume that malloc(0) will return a non-NULL pointer.
Typically, though, the output of malloc(0) will be safe to pass to
realloc() and free().

In any case, reading the section in the C FAQ on null pointers is
highly recommended to remove confusion regarding null pointers in C,
since this is a subject of much confusion to even experienced
programmers. In particular, if you do not understand why using
calloc() to allocate a struct that contains pointer members or why
calling memset() to initialize such a struct to all-bytes-zero is
wrong, reread that section again. (Note that there are *lots* of
examples of code in the krb5 source tree that erroneously calls
memset() to zero a struct, and we should fix these somehow
eventually.)

== Brace placement ==

Control flow statements that have a single statement as their body
should nevertheless have braces around their bodies if the body is
more than one line long, especially in the case of stacked multiple
if-else clauses; use:

<pre>
if (x) {
if (y)
foo();
else
bar();
}
</pre>

instead of:

<pre>
/* bad style */
if (x)
if (y)
foo();
else
bar();
</pre>

which, while legible to the compiler, may confuse human readers and
make the code less maintainable, especially if new branches get added
to any of the clauses.

If you are writing a do-while loop that has only one statement in its
body, put braces around it anyway, since the while clause may be
mistaken for a while loop with an empty body. Don't do this:

<pre>
/* bad style */
do
foo();
while (x);
</pre>

Instead, write this:

<pre>
/* better style */
do {
foo();
} while (x);
</pre>

== Preprocessor conditionals ==

Almost never intersperse conditional compilation
directives with control flow statements, as some combination of
<code>#define</code>d symbols may result in statements getting eaten by dangling
bits of control flow statements. When it is not possible to avoid
this questionable practice (you really should rewrite the relevant
code section), make use of redundant braces to ensure that a compiler
error will result in preference to incorrect runtime behavior (such as
inadvertently providing someone with a root shell).

Do not intersperse conditional compilation directives with control
flow statements in such a way that confuses emacs cc-mode. Not only
does emacs get confused, but the code becomes more difficult to read
and maintain. Therefore, avoid code like this:

<pre>
/* bad style */
if (x) {
f();
}
#ifdef FOO
else if (y) {
#else
else {
#endif
g();
}
</pre>

Put comments after conditional compilation directives such as "#else"
and "#endif". Make them correspond to the sense of the value that
controls the compilation of the section they are closing, i.e.

<pre>
#ifdef FOO
/* ... */
#else /* !FOO */
/* ... */
#endif /* !FOO */
</pre>

Also, in the case of more complex conditional compilation directives,
write the comments like this:

<pre>
#if defined(FOO) || defined(BAR)
/* ... */
#else /* !(defined(FOO) || defined(BAR)) */
/* ... */
#endif /* !(defined(FOO) || defined(BAR)) */
</pre>

== Local variables ==

Do not declare variables in an inner scope, e.g. inside the compound
substatement of an if statement, unless the complexity of the code
really demands that the variables be declared that way. In such
situations, the function could probably stand to be broken up into
smaller chunks anyway. Do not declare variables in an inner scope
that shadow ones in an outer scope, since this leads to confusion.
Also, some debugging environments, such as gdb under Solaris, can't
see variables declared in an inner scope, so declaring such variables
will make maintenance more difficult as well.

== Placement of parentheses ==

Parenthesize expressions that may be confusing, particularly where C's
precedences are broken. For example, the shift operators have lower
precedence than the +, -, *, /, and % operators. Perhaps the most
familiar C precedence quirk is that equality and relational operators
are of higher precedence than assignment operators. Less well known
is that the bitwise operators are of a lower precedence than equality
and relational operators.

The sizeof operator takes either a unary expression or a parenthesized
type name. It is not necessary to parenthesize the operand of sizeof
if it is applied to a unary expression, but still, always parenthesize
the operand of the sizeof operator. The sizeof operator does not
evaluate its operand if it is a unary expression, so usages such as

<pre>
s = sizeof(++foo);
</pre>

should be avoided for the sake of sanity and readability.

== Function-like macros ==

Macros should have all-uppercase names. If it is necessary to use
multiple statements, use braces, and wrap the whole thing in a
do-while(0) construct, such as

<pre>
#define FOOMACRO(x, y) do { \
foo = (x) + (y); \
f(y); \
} while (0)
</pre>

Leave off the semicolon at the end of a function-like macro, so that
it can be mostly used like a call to a function without a return
value. Line up the backslashes to make it more readable. Use M-x
c-backslash-region in emacs to do neat lined-up backslashes.
Parenthesize uses of arguments in the replacement text of a macro in
order to prevent weird interactions.

== Namespaces ==

The C standard reserves a bunch of namespaces for the implementation.
Don't stomp on them. For practical purposes, any identifier with a
leading underscore should not be used. (Technically, ^_[a-z].* are
reserved only for file scope, so should be safe for things smaller
than file scope, but it's better to be paranoid in this case.)

POSIX reserves typedef names ending with _t as well.

Recall that errno is a reserved identifier, and is permitted to be a
macro. Therefore, do not use errno as the name of a structure member,
etc.

Reserved namespaces are somewhat more restricted than this; read the
appropriate section of the C standard if you have questions.

If you're writing new library code, pick a short prefix and stick with
it for any identifier with external linkage. If for some reason a
library needs to have external symbols that should not be visible to
the application, pick another (related) prefix to use for the internal
globals. This applies to typedef names, tag names, and preprocessor
identifiers as well.

For the krb5 library, the prefix for public global symbols is "krb5_".
Use "krb5int_" as a prefix for library internal globals. Avoid using
"__" in symbol names, as it may confuse C++ implementations. There
are admittedly a number of places where we leak thing into the
namespace; we should try to fix these.

Header files should also not leak symbols. Usually using the upcased
version of the prefix you've picked will suffice, e.g. "KRB5_" as a
CPP symbol prefix corresponding to "krb5_". In general, do not define
macros that are lowercase, in order to avoid confusion and to prevent
namespace collisions.

The C standard only guarantees six case-insensitive characters to be
significant in external identifiers; this is largely regarded as
obsolescent even in 1989 and we will ignore it. It does, however,
only guarantee 31 case-sensitive characters to be signficant in
internal identifiers, so do not use identifiers that differ beyond the
31st character. This is unlikely to be a problem, though.

== Misc. to be sorted ==

Assume, for most purposes, working ANSI/ISO C ('89, not '99) support,
both for internal use and for applications compiling against Kerberos
header files and libraries. Some exceptions are noted below.

While it is syntactically correct to call through a function pointer
without applying a dereference operator to it, do not write code that
does this. It is easier to see that the function call is actually
taking place through a function pointer if you write an explicit
dereference. However, do not explicitly take the address of a
function in order to assign it to a function pointer, since a function
name degrades into a pointer. Thus:

<pre>
int (*fp)(void);
int foofunc(void);
fp = foofunc;
x = (*fp)();
</pre>

In general, do not take the address of an array. It does not return a
pointer to the first element; it returns a pointer to the array
itself. These are often identical when cast to an integral type, but
they are inherently of different types themselves. Functions that
take array types or pointers to array types as arguments can be
particularly trouble-prone.

If a function is declared to return a value, do not call "return"
without an argument or allow the flow of control to fall off the end
of the function.

Always declare the return type of a function, even if it returns int.
Yes, this means declaring main() to return int, since main() is
required to return int by the standard. If a function is not supposed
to return a value, declare it as returning void rather than omitting
the return type, which will default the return type to int.

Try to use ANSI C prototype-style function definitions in preference
to K&R style definitions. When using K&R style function definitions,
declare all the argument types, even those that are int, but beware of
any narrow types in the argument list.

Don't pass around structures except by address. We may relax this
restriction for non-API functions, though.

For new functions, input parameters should go before output parameters
in the call signature. There are exceptions, such as a context-like
parameter.

Every function should have block comment preceding it describing
briefly in complete sentences what it does, what inputs and outputs it
has, and what error codes it can return. It should also describe any
unusual aspects of the function. At some point we will want to put
some of this information into a machine-parsable form.

Strive to make your code capable of compiling using "gcc -Wall
-Wmissing-prototypes -Wtraditional -Wcast-qual -Wcast-align
-Wconversion -Waggregate-return -pedantic" [XXX need to rethink this
somewhat] without generating any errors or warnings. Do not, however,
compile using the "-ansi" flag to gcc, since that can result in odd
behavior with header files on some systems, causing some necessary
symbols to not be defined.

Release Meeting Minutes

2008-10-14T17:07:54Z

KenRaeburn: /* September 2008 */ add 09-30 minutes

Public minutes of Kerberos Consortium Release Meetings arranged in reverse chronological order:

==October 2008==

[[Release Meeting Minutes/2008-10-08 | October 8, 2008 (2008-10-08)]]

==September 2008==

[[Release Meeting Minutes/2008-09-30 | September 30, 2008 (2008-09-30)]]

[[Release Meeting Minutes/2008-09-09 | September 9, 2008 (2008-09-09)]]

[[Release Meeting Minutes/2008-09-02 | September 2, 2008 (2008-09-02)]]

==August 2008==

[[Release Meeting Minutes/2008-08-26 | August 26, 2008 (2008-08-26)]]

[[Release Meeting Minutes/2008-08-04 | August 4, 2008 (2008-08-04)]]

==July 2008==

[[Release Meeting Minutes/2008-07-21 | July 21, 2008 (2008-07-21)]]

[[Release Meeting Minutes/2008-07-14 | July 14, 2008 (2008-07-14)]]

[[Release Meeting Minutes/2008-07-07 | July 7, 2008 (2008-07-07)]]

==June 2008==

[[Release Meeting Minutes/2008-06-30 | June 30, 2008 (2008-06-30)]]

[[Release Meeting Minutes/2008-06-23 | June 23, 2008 (2008-06-23)]]

[[Release Meeting Minutes/2008-06-16 | June 16, 2008 (2008-06-16)]]

==May 2008==

[[Release Meeting Minutes/2008-05-19 | May 19, 2008 (2008-05-19)]]

[[Release Meeting Minutes/2008-05-12 | May 12, 2008 (2008-05-12)]]

[[Release Meeting Minutes/2008-05-05 | May 5, 2008 (2008-05-05)]]

==April 2008==
[[Release Meeting Minutes/2008-04-28 | April 28, 2008 (2008-04-28)]]

[[Release Meeting Minutes/2008-04-14 | April 14, 2008 (2008-04-14)]]

==March 2008==
[[Release Meeting Minutes/2008-03-31 |March 31, 2008 (2008-03-31)]]

[[Release Meeting Minutes/2008-03-24 |March 24, 2008 (2008-03-24)]]

[[Release Meeting Minutes/2008-03-17 |March 17, 2008 (2008-03-17)]]

[[Release Meeting Minutes/2008-03-10 |March 10, 2008 (2008-03-10)]]

==February 2008==
[[Release Meeting Minutes/2008-02-04 |February 4, 2008 (2008-02-04)]]

==January 2008==
[[Release Meeting Minutes/2008-01-28 |January 28, 2008 (2008-01-28)]]

[[Release Meeting Minutes/2008-01-07 |January 7, 2008 (2008-01-07)]]

==December 2007==
[[Release Meeting Minutes/2007-12-17|December 17, 2007 (2007-12-17)]]

[[Release Meeting Minutes/2007-12-10|December 10, 2007 (2007-12-10)]]

Release Meeting Minutes/2008-09-30

2008-10-14T17:07:11Z

KenRaeburn: New page: ==Meeting notes for 2008-09-30== In room: Ken Alexis Tom Zhanna Greg Justin Steve; on phone: Sam H, Will F. ... (started taking notes late) ... Discussion of master key rollover, mostly...

==Meeting notes for 2008-09-30==

In room: Ken Alexis Tom Zhanna Greg Justin Steve; on phone: Sam H, Will F.

... (started taking notes late) ...

Discussion of master key rollover, mostly seems to have agreement.
Updating project page, timeline unchanged.
Will will add more intermediate implementation milestones.

Project proposal process revisions.

Currently need to provide a lot of detail, big hurdle. Could use this process only for large projects, or streamline process, or both.

Sam asks what problem is. Want a starting point for discussion that has less detail, less onerous to make an initial proposal. Want a lighter-weight initial step for discussion. Sam originally envisioned the process being used that way, but without it being too formalized and creating too much work to even start up a project. Tom: To the extent that it can be informal, mailing list is good enough; for stuff people may want to look up later, need wiki. May also want to keep around (wiki, or issue tracker) ideas that have been previously brought up and shot down. Maybe turn into iterative process.

Difficult to get anyone to approve a project. Possible approach, make a ticket in RT and assign it. Or, person proposing project needs to do the work of finding support and approval; may be too difficult for someone just getting started but fine for established developers. Could assign a sponsor/mentor/parter/spirit-guide/whatever for new developers to help shepherd things along.

Someone needs to make sure reviews actually happen. Tom?

Maybe a small list or set of people who can be emailed?

Tom suggests krbcore members should be responsible for reviewing code. Could automate assignment in RT when a ticket goes into "review" state. Also, can start sending ticket state changes to krbcore list. May need to update krbcore list membership.

Pages needed in wiki? Enrollment process for new committers. How to start doing stuff (Will's list). Expectations for krbcore members. Code review process. Expectations in terms of testing contributions.

Some nightly test runs are failing. New krbdev machine needs some reconfiguration, can't download readable log files right now.

Krbweb test

2008-10-08T19:30:21Z

KenRaeburn:

{{krbweb-public-page}}

This is a test document.

Hello!

Release Meeting Minutes

2008-09-02T17:24:41Z

KenRaeburn:

Public minutes of Kerberos Consortium Release Meetings arranged in reverse chronological order:

==September 2008==

[[Release Meeting Minutes/2008-09-02 | September 2, 2008 (2008-09-02)]]

==August 2008==

[[Release Meeting Minutes/2008-08-26 | August 26, 2008 (2008-08-26)]]

[[Release Meeting Minutes/2008-08-04 | August 4, 2008 (2008-08-04)]]

==July 2008==

[[Release Meeting Minutes/2008-07-21 | July 21, 2008 (2008-07-21)]]

[[Release Meeting Minutes/2008-07-14 | July 14, 2008 (2008-07-14)]]

[[Release Meeting Minutes/2008-07-07 | July 7, 2008 (2008-07-07)]]

==June 2008==

[[Release Meeting Minutes/2008-06-30 | June 30, 2008 (2008-06-30)]]

[[Release Meeting Minutes/2008-06-23 | June 23, 2008 (2008-06-23)]]

[[Release Meeting Minutes/2008-06-16 | June 16, 2008 (2008-06-16)]]

==May 2008==

[[Release Meeting Minutes/2008-05-19 | May 19, 2008 (2008-05-19)]]

[[Release Meeting Minutes/2008-05-12 | May 12, 2008 (2008-05-12)]]

[[Release Meeting Minutes/2008-05-05 | May 5, 2008 (2008-05-05)]]

==April 2008==
[[Release Meeting Minutes/2008-04-28 | April 28, 2008 (2008-04-28)]]

[[Release Meeting Minutes/2008-04-14 | April 14, 2008 (2008-04-14)]]

==March 2008==
[[Release Meeting Minutes/2008-03-31 |March 31, 2008 (2008-03-31)]]

[[Release Meeting Minutes/2008-03-24 |March 24, 2008 (2008-03-24)]]

[[Release Meeting Minutes/2008-03-17 |March 17, 2008 (2008-03-17)]]

[[Release Meeting Minutes/2008-03-10 |March 10, 2008 (2008-03-10)]]

==February 2008==
[[Release Meeting Minutes/2008-02-04 |February 4, 2008 (2008-02-04)]]

==January 2008==
[[Release Meeting Minutes/2008-01-28 |January 28, 2008 (2008-01-28)]]

[[Release Meeting Minutes/2008-01-07 |January 7, 2008 (2008-01-07)]]

==December 2007==
[[Release Meeting Minutes/2007-12-17|December 17, 2007 (2007-12-17)]]

[[Release Meeting Minutes/2007-12-10|December 10, 2007 (2007-12-10)]]

Release Meeting Minutes/2008-09-02

2008-09-02T17:23:22Z

KenRaeburn: New page: '''Release Meeting Notes 9/2/2008''' Status reports: Will: Long weekend. Will email today a timeline for master key rollover work. Some discussion of checklist, and testing for regress...

'''Release Meeting Notes 9/2/2008'''

Status reports:

Will: Long weekend. Will email today a timeline for master key rollover work. Some discussion of checklist, and testing for regressions.

Tom: Working on RT upgrade, and cleaning up some warnings with Ken. RT server migration should happen soon, should speed things up.

Zhanna: Working on replay cache code, ready to test performance changes. Planning a new design discussion.

Ken: Integrated some patches from Apple and lxs, fixed misc warnings, some things flagged by Coverity, make rules to help out with running Coverity. To do: More patches, domain_realm referrals, iprop.

Justin: Working on KIM, some UI stuff on Touchstone because the Touchstone team has little UI experience.

Alexandra: More Apple patches, more KIM work.

Projects/domain realm referrals

2008-07-23T20:53:41Z

KenRaeburn: /* Open Issues */ change name to "notes" and drop default service name list idea

{{project-review|2008-07-17}}

== Desired Changes ==

Eliminate the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral ([https://datatracker.ietf.org/drafts/draft-ietf-krb-wg-kerberos-referrals/ draft-ietf-krb-wg-kerberos-referrals]) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.

== Functional Requirements ==

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

== Design ==

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:
* the request is not a user-to-user authentication request
* the server principal name is unknown
* the canonicalize flag is set in the request
* the requested server principal has exactly two components
* either:
** the name type is NT-UNKNOWN and the first component is listed in the config file under "host_based_services"; or
** the name type is NT-SRV-HST
* the first component is not in a list configured in the KDC config file under "no_host_referral"
* the second component looks like a fully-qualified domain name
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.

A listing in "no_host_referral" means no referral processing will be done, even if the client uses NT-SRV-HST or the service is also listed in "host_based_services".

The special service name "*" in the config file will match any service. So "host_based_services = *" means all NT-UNKNOWN principals will be treated like NT-SRV-HST, that is, referral processing will be done if they actually look like host-based principal names; and "no_host_referral = *" will disable referral processing altogether, regardless of the "host_based_services" setting or the client-supplied name type.

The config file entries used, from the per-realm data or from libdefaults, are "host_based_services" and "no_host_referral". They may be specified multiple times, and each string value contains one or more (space- or comma-separated) service names.

With support for "no_host_referral = *" and the expectation that few sites will want to disable this processing completely, I don't see a special need for a separate config file flag for enabling and disabling referral processing explicitly.

== Tasks/Milestones ==

* Library changes
* Library change test case
* KDC detection of the relevant cases
* KDC implementation of change of principal name

== Testing Plan ==

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Manual test of unknown name that maps to the local realm.

== Notes ==

Caching the lists of service names isn't in the plan; that can be added later if there's a performance concern.

==Review==

This section documents the review of the project according to [[Project policy]].
It is divided into multiple sections. First, approvals should be listed. To list an approval type
:<nowiki>#~~~~</nowiki>
on its own line.
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with
:<nowiki>--~~~~</nowiki>
and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.

===Approvals===

===Discussion===

I believe that name type needs to be considered and that Jeff Hutzelman's proposal on krbdev should be adopted.; this is not quite a blocking objection but I'd appreciate explicit closure before you go forward with another option.
--[[User:SamHartman|SamHartman]] 13:45, 10 May 2008 (EDT)

: I think today's new version should address Jeff's comments. Posting a new message asking for review.... --[[User:KenRaeburn|KenRaeburn]] 16:17, 3 July 2008 (EDT)

Projects/domain realm referrals

2008-07-18T16:23:33Z

KenRaeburn: /* Open Issues */

{{project-review|2008-07-17}}

== Desired Changes ==

Eliminate the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral ([https://datatracker.ietf.org/drafts/draft-ietf-krb-wg-kerberos-referrals/ draft-ietf-krb-wg-kerberos-referrals]) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.

== Functional Requirements ==

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

== Design ==

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:
* the request is not a user-to-user authentication request
* the server principal name is unknown
* the canonicalize flag is set in the request
* the requested server principal has exactly two components
* either:
** the name type is NT-UNKNOWN and the first component is listed in the config file under "host_based_services"; or
** the name type is NT-SRV-HST
* the first component is not in a list configured in the KDC config file under "no_host_referral"
* the second component looks like a fully-qualified domain name
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.

A listing in "no_host_referral" means no referral processing will be done, even if the client uses NT-SRV-HST or the service is also listed in "host_based_services".

The special service name "*" in the config file will match any service. So "host_based_services = *" means all NT-UNKNOWN principals will be treated like NT-SRV-HST, that is, referral processing will be done if they actually look like host-based principal names; and "no_host_referral = *" will disable referral processing altogether, regardless of the "host_based_services" setting or the client-supplied name type.

The config file entries used, from the per-realm data or from libdefaults, are "host_based_services" and "no_host_referral". They may be specified multiple times, and each string value contains one or more (space- or comma-separated) service names.

With support for "no_host_referral = *" and the expectation that few sites will want to disable this processing completely, I don't see a special need for a separate config file flag for enabling and disabling referral processing explicitly.

== Tasks/Milestones ==

* Library changes
* Library change test case
* KDC detection of the relevant cases
* KDC implementation of change of principal name

== Testing Plan ==

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Manual test of unknown name that maps to the local realm.

== Open Issues ==

Should all services to process this way when NT-UNKNOWN is used be specified in the config file, or should we start with the hardcoded list in the 524 name conversion code and add from there? (The exception list could still override, but wouldn't distinguish between NT-UNKNOWN and NT-SRV-HST.) Probably default to an empty list.

Caching the lists of service names isn't in the plan; that can be added later if there's a performance concern.

==Review==

This section documents the review of the project according to [[Project policy]].
It is divided into multiple sections. First, approvals should be listed. To list an approval type
:<nowiki>#~~~~</nowiki>
on its own line.
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with
:<nowiki>--~~~~</nowiki>
and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.

===Approvals===

===Discussion===

I believe that name type needs to be considered and that Jeff Hutzelman's proposal on krbdev should be adopted.; this is not quite a blocking objection but I'd appreciate explicit closure before you go forward with another option.
--[[User:SamHartman|SamHartman]] 13:45, 10 May 2008 (EDT)

: I think today's new version should address Jeff's comments. Posting a new message asking for review.... --[[User:KenRaeburn|KenRaeburn]] 16:17, 3 July 2008 (EDT)

Projects/domain realm referrals

2008-07-03T20:21:13Z

KenRaeburn: /* Open Issues */ note the lack of caching

{{project-review|2008-07-17}}

== Desired Changes ==

Eliminate the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral ([https://datatracker.ietf.org/drafts/draft-ietf-krb-wg-kerberos-referrals/ draft-ietf-krb-wg-kerberos-referrals]) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.

== Functional Requirements ==

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

== Design ==

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:
* the request is not a user-to-user authentication request
* the server principal name is unknown
* the canonicalize flag is set in the request
* the requested server principal has exactly two components
* either:
** the name type is NT-UNKNOWN and the first component is listed in the config file under "host_based_services"; or
** the name type is NT-SRV-HST
* the first component is not in a list configured in the KDC config file under "no_host_referral"
* the second component looks like a fully-qualified domain name
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.

A listing in "no_host_referral" means no referral processing will be done, even if the client uses NT-SRV-HST or the service is also listed in "host_based_services".

The special service name "*" in the config file will match any service. So "host_based_services = *" means all NT-UNKNOWN principals will be treated like NT-SRV-HST, that is, referral processing will be done if they actually look like host-based principal names; and "no_host_referral = *" will disable referral processing altogether, regardless of the "host_based_services" setting or the client-supplied name type.

The config file entries used, from the per-realm data or from libdefaults, are "host_based_services" and "no_host_referral". They may be specified multiple times, and each string value contains one or more (space- or comma-separated) service names.

With support for "no_host_referral = *" and the expectation that few sites will want to disable this processing completely, I don't see a special need for a separate config file flag for enabling and disabling referral processing explicitly.

== Tasks/Milestones ==

* Library changes
* Library change test case
* KDC detection of the relevant cases
* KDC implementation of change of principal name

== Testing Plan ==

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Manual test of unknown name that maps to the local realm.

== Open Issues ==

Should all services to process this way when NT-UNKNOWN is used be specified in the config file, or should we start with the hardcoded list in the 524 name conversion code and add from there? (The exception list could still override, but wouldn't distinguish between NT-UNKNOWN and NT-SRV-HST.)

Caching the lists of service names isn't in the plan; that can be added later if there's a performance concern.

==Review==

This section documents the review of the project according to [[Project policy]].
It is divided into multiple sections. First, approvals should be listed. To list an approval type
:<nowiki>#~~~~</nowiki>
on its own line.
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with
:<nowiki>--~~~~</nowiki>
and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.

===Approvals===

===Discussion===

I believe that name type needs to be considered and that Jeff Hutzelman's proposal on krbdev should be adopted.; this is not quite a blocking objection but I'd appreciate explicit closure before you go forward with another option.
--[[User:SamHartman|SamHartman]] 13:45, 10 May 2008 (EDT)

: I think today's new version should address Jeff's comments. Posting a new message asking for review.... --[[User:KenRaeburn|KenRaeburn]] 16:17, 3 July 2008 (EDT)

Projects/domain realm referrals

2008-07-03T20:17:33Z

KenRaeburn: /* Discussion */

{{project-review|2008-07-17}}

== Desired Changes ==

Eliminate the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral ([https://datatracker.ietf.org/drafts/draft-ietf-krb-wg-kerberos-referrals/ draft-ietf-krb-wg-kerberos-referrals]) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.

== Functional Requirements ==

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

== Design ==

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:
* the request is not a user-to-user authentication request
* the server principal name is unknown
* the canonicalize flag is set in the request
* the requested server principal has exactly two components
* either:
** the name type is NT-UNKNOWN and the first component is listed in the config file under "host_based_services"; or
** the name type is NT-SRV-HST
* the first component is not in a list configured in the KDC config file under "no_host_referral"
* the second component looks like a fully-qualified domain name
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.

A listing in "no_host_referral" means no referral processing will be done, even if the client uses NT-SRV-HST or the service is also listed in "host_based_services".

The special service name "*" in the config file will match any service. So "host_based_services = *" means all NT-UNKNOWN principals will be treated like NT-SRV-HST, that is, referral processing will be done if they actually look like host-based principal names; and "no_host_referral = *" will disable referral processing altogether, regardless of the "host_based_services" setting or the client-supplied name type.

The config file entries used, from the per-realm data or from libdefaults, are "host_based_services" and "no_host_referral". They may be specified multiple times, and each string value contains one or more (space- or comma-separated) service names.

With support for "no_host_referral = *" and the expectation that few sites will want to disable this processing completely, I don't see a special need for a separate config file flag for enabling and disabling referral processing explicitly.

== Tasks/Milestones ==

* Library changes
* Library change test case
* KDC detection of the relevant cases
* KDC implementation of change of principal name

== Testing Plan ==

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Manual test of unknown name that maps to the local realm.

== Open Issues ==

Should all services to process this way when NT-UNKNOWN is used be specified in the config file, or should we start with the hardcoded list in the 524 name conversion code and add from there? (The exception list could still override, but wouldn't distinguish between NT-UNKNOWN and NT-SRV-HST.)

==Review==

This section documents the review of the project according to [[Project policy]].
It is divided into multiple sections. First, approvals should be listed. To list an approval type
:<nowiki>#~~~~</nowiki>
on its own line.
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with
:<nowiki>--~~~~</nowiki>
and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.

===Approvals===

===Discussion===

I believe that name type needs to be considered and that Jeff Hutzelman's proposal on krbdev should be adopted.; this is not quite a blocking objection but I'd appreciate explicit closure before you go forward with another option.
--[[User:SamHartman|SamHartman]] 13:45, 10 May 2008 (EDT)

: I think today's new version should address Jeff's comments. Posting a new message asking for review.... --[[User:KenRaeburn|KenRaeburn]] 16:17, 3 July 2008 (EDT)

Projects/domain realm referrals

2008-07-03T20:05:55Z

KenRaeburn: revise review date

{{project-review|2008-07-17}}

== Desired Changes ==

Eliminate the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral ([https://datatracker.ietf.org/drafts/draft-ietf-krb-wg-kerberos-referrals/ draft-ietf-krb-wg-kerberos-referrals]) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.

== Functional Requirements ==

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

== Design ==

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:
* the request is not a user-to-user authentication request
* the server principal name is unknown
* the canonicalize flag is set in the request
* the requested server principal has exactly two components
* either:
** the name type is NT-UNKNOWN and the first component is listed in the config file under "host_based_services"; or
** the name type is NT-SRV-HST
* the first component is not in a list configured in the KDC config file under "no_host_referral"
* the second component looks like a fully-qualified domain name
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.

A listing in "no_host_referral" means no referral processing will be done, even if the client uses NT-SRV-HST or the service is also listed in "host_based_services".

The special service name "*" in the config file will match any service. So "host_based_services = *" means all NT-UNKNOWN principals will be treated like NT-SRV-HST, that is, referral processing will be done if they actually look like host-based principal names; and "no_host_referral = *" will disable referral processing altogether, regardless of the "host_based_services" setting or the client-supplied name type.

The config file entries used, from the per-realm data or from libdefaults, are "host_based_services" and "no_host_referral". They may be specified multiple times, and each string value contains one or more (space- or comma-separated) service names.

With support for "no_host_referral = *" and the expectation that few sites will want to disable this processing completely, I don't see a special need for a separate config file flag for enabling and disabling referral processing explicitly.

== Tasks/Milestones ==

* Library changes
* Library change test case
* KDC detection of the relevant cases
* KDC implementation of change of principal name

== Testing Plan ==

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Manual test of unknown name that maps to the local realm.

== Open Issues ==

Should all services to process this way when NT-UNKNOWN is used be specified in the config file, or should we start with the hardcoded list in the 524 name conversion code and add from there? (The exception list could still override, but wouldn't distinguish between NT-UNKNOWN and NT-SRV-HST.)

==Review==

This section documents the review of the project according to [[Project policy]].
It is divided into multiple sections. First, approvals should be listed. To list an approval type
:<nowiki>#~~~~</nowiki>
on its own line.
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with
:<nowiki>--~~~~</nowiki>
and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.

===Approvals===

===Discussion===

I believe that name type needs to be considered and that Jeff Hutzelman's proposal on krbdev should be adopted.; this is not quite a blocking objection but I'd appreciate explicit closure before you go forward with another option.
--[[User:SamHartman|SamHartman]] 13:45, 10 May 2008 (EDT)

Projects/domain realm referrals

2008-07-03T20:04:27Z

KenRaeburn: /* Design */

{{project-review|2008-05-12}}

== Desired Changes ==

Eliminate the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral ([https://datatracker.ietf.org/drafts/draft-ietf-krb-wg-kerberos-referrals/ draft-ietf-krb-wg-kerberos-referrals]) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.

== Functional Requirements ==

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

== Design ==

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:
* the request is not a user-to-user authentication request
* the server principal name is unknown
* the canonicalize flag is set in the request
* the requested server principal has exactly two components
* either:
** the name type is NT-UNKNOWN and the first component is listed in the config file under "host_based_services"; or
** the name type is NT-SRV-HST
* the first component is not in a list configured in the KDC config file under "no_host_referral"
* the second component looks like a fully-qualified domain name
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.

A listing in "no_host_referral" means no referral processing will be done, even if the client uses NT-SRV-HST or the service is also listed in "host_based_services".

The special service name "*" in the config file will match any service. So "host_based_services = *" means all NT-UNKNOWN principals will be treated like NT-SRV-HST, that is, referral processing will be done if they actually look like host-based principal names; and "no_host_referral = *" will disable referral processing altogether, regardless of the "host_based_services" setting or the client-supplied name type.

The config file entries used, from the per-realm data or from libdefaults, are "host_based_services" and "no_host_referral". They may be specified multiple times, and each string value contains one or more (space- or comma-separated) service names.

With support for "no_host_referral = *" and the expectation that few sites will want to disable this processing completely, I don't see a special need for a separate config file flag for enabling and disabling referral processing explicitly.

== Tasks/Milestones ==

* Library changes
* Library change test case
* KDC detection of the relevant cases
* KDC implementation of change of principal name

== Testing Plan ==

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Manual test of unknown name that maps to the local realm.

== Open Issues ==

Should all services to process this way when NT-UNKNOWN is used be specified in the config file, or should we start with the hardcoded list in the 524 name conversion code and add from there? (The exception list could still override, but wouldn't distinguish between NT-UNKNOWN and NT-SRV-HST.)

==Review==

This section documents the review of the project according to [[Project policy]].
It is divided into multiple sections. First, approvals should be listed. To list an approval type
:<nowiki>#~~~~</nowiki>
on its own line.
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with
:<nowiki>--~~~~</nowiki>
and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.

===Approvals===

===Discussion===

I believe that name type needs to be considered and that Jeff Hutzelman's proposal on krbdev should be adopted.; this is not quite a blocking objection but I'd appreciate explicit closure before you go forward with another option.
--[[User:SamHartman|SamHartman]] 13:45, 10 May 2008 (EDT)

Projects/domain realm referrals

2008-07-03T19:46:27Z

KenRaeburn: /* Design */ get flag name right

{{project-review|2008-05-12}}

== Desired Changes ==

Eliminate the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral ([https://datatracker.ietf.org/drafts/draft-ietf-krb-wg-kerberos-referrals/ draft-ietf-krb-wg-kerberos-referrals]) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.

== Functional Requirements ==

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

== Design ==

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:
* the request is not a user-to-user authentication request
* the server principal name is unknown
* the canonicalize flag is set in the request
* the requested server principal has two components
* either:
** the name type is NT-UNKNOWN and the first component is listed in the config file under "host_based_services"; or
** the name type is NT-HOST-BASED
* the first component is not in a list configured in the KDC config file under "no_host_referral"
* the second component looks like a fully-qualified domain name
* ''(there may be additional conditions that should be imposed)''
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.

The config file entries used, from the per-realm data or in libdefaults, are: "host_based_services", "no_host_referral".

== Tasks/Milestones ==

* Library changes
* Library change test case
* KDC detection of the relevant cases
* KDC implementation of change of principal name

== Testing Plan ==

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Manual test of unknown name that maps to the local realm.

== Open Issues ==

Should all services to process this way when NT-UNKNOWN is used be specified in the config file, or should we start with the hardcoded list in the 524 name conversion code and add from there? (The exception list could still override, but wouldn't distinguish between NT-UNKNOWN and NT-SRV-HST.)

==Review==

This section documents the review of the project according to [[Project policy]].
It is divided into multiple sections. First, approvals should be listed. To list an approval type
:<nowiki>#~~~~</nowiki>
on its own line.
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with
:<nowiki>--~~~~</nowiki>
and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.

===Approvals===

===Discussion===

I believe that name type needs to be considered and that Jeff Hutzelman's proposal on krbdev should be adopted.; this is not quite a blocking objection but I'd appreciate explicit closure before you go forward with another option.
--[[User:SamHartman|SamHartman]] 13:45, 10 May 2008 (EDT)

Projects/domain realm referrals

2008-07-03T19:45:47Z

KenRaeburn: /* Open Issues */

{{project-review|2008-05-12}}

== Desired Changes ==

Eliminate the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral ([https://datatracker.ietf.org/drafts/draft-ietf-krb-wg-kerberos-referrals/ draft-ietf-krb-wg-kerberos-referrals]) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.

== Functional Requirements ==

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

== Design ==

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:
* the request is not a user-to-user authentication request
* the server principal name is unknown
* the referral flag is set in the request
* the requested server principal has two components
* either:
** the name type is NT-UNKNOWN and the first component is listed in the config file under "host_based_services"; or
** the name type is NT-HOST-BASED
* the first component is not in a list configured in the KDC config file under "no_host_referral"
* the second component looks like a fully-qualified domain name
* ''(there may be additional conditions that should be imposed)''
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.

The config file entries used, from the per-realm data or in libdefaults, are: "host_based_services", "no_host_referral".

== Tasks/Milestones ==

* Library changes
* Library change test case
* KDC detection of the relevant cases
* KDC implementation of change of principal name

== Testing Plan ==

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Manual test of unknown name that maps to the local realm.

== Open Issues ==

Should all services to process this way when NT-UNKNOWN is used be specified in the config file, or should we start with the hardcoded list in the 524 name conversion code and add from there? (The exception list could still override, but wouldn't distinguish between NT-UNKNOWN and NT-SRV-HST.)

==Review==

This section documents the review of the project according to [[Project policy]].
It is divided into multiple sections. First, approvals should be listed. To list an approval type
:<nowiki>#~~~~</nowiki>
on its own line.
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with
:<nowiki>--~~~~</nowiki>
and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.

===Approvals===

===Discussion===

I believe that name type needs to be considered and that Jeff Hutzelman's proposal on krbdev should be adopted.; this is not quite a blocking objection but I'd appreciate explicit closure before you go forward with another option.
--[[User:SamHartman|SamHartman]] 13:45, 10 May 2008 (EDT)

Projects/domain realm referrals

2008-07-03T19:42:45Z

KenRaeburn: /* Open Issues */

{{project-review|2008-05-12}}

== Desired Changes ==

Eliminate the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral ([https://datatracker.ietf.org/drafts/draft-ietf-krb-wg-kerberos-referrals/ draft-ietf-krb-wg-kerberos-referrals]) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.

== Functional Requirements ==

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

== Design ==

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:
* the request is not a user-to-user authentication request
* the server principal name is unknown
* the referral flag is set in the request
* the requested server principal has two components
* either:
** the name type is NT-UNKNOWN and the first component is listed in the config file under "host_based_services"; or
** the name type is NT-HOST-BASED
* the first component is not in a list configured in the KDC config file under "no_host_referral"
* the second component looks like a fully-qualified domain name
* ''(there may be additional conditions that should be imposed)''
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.

The config file entries used, from the per-realm data or in libdefaults, are: "host_based_services", "no_host_referral".

== Tasks/Milestones ==

* Library changes
* Library change test case
* KDC detection of the relevant cases
* KDC implementation of change of principal name

== Testing Plan ==

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Manual test of unknown name that maps to the local realm.

== Open Issues ==

Should all services to process this way be specified in the config file, or should we also use the hardcoded list in the 524 name conversion code?

==Review==

This section documents the review of the project according to [[Project policy]].
It is divided into multiple sections. First, approvals should be listed. To list an approval type
:<nowiki>#~~~~</nowiki>
on its own line.
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with
:<nowiki>--~~~~</nowiki>
and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.

===Approvals===

===Discussion===

I believe that name type needs to be considered and that Jeff Hutzelman's proposal on krbdev should be adopted.; this is not quite a blocking objection but I'd appreciate explicit closure before you go forward with another option.
--[[User:SamHartman|SamHartman]] 13:45, 10 May 2008 (EDT)

Projects/domain realm referrals

2008-07-03T18:42:25Z

KenRaeburn: /* Desired Changes */ url for referrals draft

{{project-review|2008-05-12}}

== Desired Changes ==

Eliminate the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral ([https://datatracker.ietf.org/drafts/draft-ietf-krb-wg-kerberos-referrals/ draft-ietf-krb-wg-kerberos-referrals]) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.

== Functional Requirements ==

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

== Design ==

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:
* the request is not a user-to-user authentication request
* the server principal name is unknown
* the referral flag is set in the request
* the requested server principal has two components
* either:
** the name type is NT-UNKNOWN and the first component is listed in the config file under "host_based_services"; or
** the name type is NT-HOST-BASED
* the first component is not in a list configured in the KDC config file under "no_host_referral"
* the second component looks like a fully-qualified domain name
* ''(there may be additional conditions that should be imposed)''
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.

The config file entries used, from the per-realm data or in libdefaults, are: "host_based_services", "no_host_referral".

== Tasks/Milestones ==

* Library changes
* Library change test case
* KDC detection of the relevant cases
* KDC implementation of change of principal name

== Testing Plan ==

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Manual test of unknown name that maps to the local realm.

== Open Issues ==

Should the list of services to process this way be specified in the config file, or is a hardcoded set adequate at first? (Meta-issue: Should config information that is realm-specific but not KDC-specific be moved into the database from the config file?)

Should we use a list of services, or just process all two-element names where the second component looks like a domain name?

Do we want to add cross-realm test cases to the automated tests? I think currently only the DejaGnu-based tests are set up to manage running a KDC and additional client programs, and they're not set up to manage multiple realms.

==Review==

This section documents the review of the project according to [[Project policy]].
It is divided into multiple sections. First, approvals should be listed. To list an approval type
:<nowiki>#~~~~</nowiki>
on its own line.
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with
:<nowiki>--~~~~</nowiki>
and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.

===Approvals===

===Discussion===

I believe that name type needs to be considered and that Jeff Hutzelman's proposal on krbdev should be adopted.; this is not quite a blocking objection but I'd appreciate explicit closure before you go forward with another option.
--[[User:SamHartman|SamHartman]] 13:45, 10 May 2008 (EDT)

Projects/domain realm referrals

2008-06-28T00:15:26Z

KenRaeburn: /* Design */

{{project-review|2008-05-12}}

== Desired Changes ==

Eliminate the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral (draft-ietf-krb-wg-kerberos-referrals) support in the KDC and providing the mapping information to clients through that protocol.

== Functional Requirements ==

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

== Design ==

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:
* the request is not a user-to-user authentication request
* the server principal name is unknown
* the referral flag is set in the request
* the requested server principal has two components
* either:
** the name type is NT-UNKNOWN and the first component is listed in the config file under "host_based_services"; or
** the name type is NT-HOST-BASED
* the first component is not in a list configured in the KDC config file under "no_host_referral"
* the second component looks like a fully-qualified domain name
* ''(there may be additional conditions that should be imposed)''
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.

The config file entries used, from the per-realm data or in libdefaults, are: "host_based_services", "no_host_referral".

== Tasks/Milestones ==

* Library changes
* Library change test case
* KDC detection of the relevant cases
* KDC implementation of change of principal name

== Testing Plan ==

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Manual test of unknown name that maps to the local realm.

== Open Issues ==

Should the list of services to process this way be specified in the config file, or is a hardcoded set adequate at first? (Meta-issue: Should config information that is realm-specific but not KDC-specific be moved into the database from the config file?)

Should we use a list of services, or just process all two-element names where the second component looks like a domain name?

Do we want to add cross-realm test cases to the automated tests? I think currently only the DejaGnu-based tests are set up to manage running a KDC and additional client programs, and they're not set up to manage multiple realms.

==Review==

This section documents the review of the project according to [[Project policy]].
It is divided into multiple sections. First, approvals should be listed. To list an approval type
:<nowiki>#~~~~</nowiki>
on its own line.
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with
:<nowiki>--~~~~</nowiki>
and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.

===Approvals===

===Discussion===

I believe that name type needs to be considered and that Jeff Hutzelman's proposal on krbdev should be adopted.; this is not quite a blocking objection but I'd appreciate explicit closure before you go forward with another option.
--[[User:SamHartman|SamHartman]] 13:45, 10 May 2008 (EDT)

Release Meeting Minutes

2008-06-23T17:36:22Z

KenRaeburn:

Public minutes of Kerberos Consortium Release Meetings arranged in reverse chronological order:

==June 2008==

[[Release Meeting Minutes/2008-06-23 | June 23, 2008 (2008-06-23)]]

==May 2008==

[[Release Meeting Minutes/2008-05-19 | May 19, 2008 (2008-05-19)]]

[[Release Meeting Minutes/2008-05-12 | May 12, 2008 (2008-05-12)]]

[[Release Meeting Minutes/2008-05-05 | May 5, 2008 (2008-05-05)]]

==April 2008==
[[Release Meeting Minutes/2008-04-28 | April 28, 2008 (2008-04-28)]]

[[Release Meeting Minutes/2008-04-14 | April 14, 2008 (2008-04-14)]]

==March 2008==
[[Release Meeting Minutes/2008-03-31 |March 31, 2008 (2008-03-31)]]

[[Release Meeting Minutes/2008-03-24 |March 24, 2008 (2008-03-24)]]

[[Release Meeting Minutes/2008-03-17 |March 17, 2008 (2008-03-17)]]

[[Release Meeting Minutes/2008-03-10 |March 10, 2008 (2008-03-10)]]

==February 2008==
[[Release Meeting Minutes/2008-02-04 |February 4, 2008 (2008-02-04)]]

==January 2008==
[[Release Meeting Minutes/2008-01-28 |January 28, 2008 (2008-01-28)]]

[[Release Meeting Minutes/2008-01-07 |January 7, 2008 (2008-01-07)]]

==December 2007==
[[Release Meeting Minutes/2007-12-17|December 17, 2007 (2007-12-17)]]

[[Release Meeting Minutes/2007-12-10|December 10, 2007 (2007-12-10)]]

Release Meeting Minutes/2008-06-23

2008-06-23T17:35:31Z

KenRaeburn: New page: Present: Ken, Tom, Alexis, Robert, Will Who's looked at the draft krb5 api doc? lxs has, saw some broken stuff and missing documentation, but it may have been a broken rev that was avail...

Present: Ken, Tom, Alexis, Robert, Will

Who's looked at the draft krb5 api doc? lxs has, saw some broken
stuff and missing documentation, but it may have been a broken rev
that was available for a few hours. Current version isn't what she
looked at.

Keytab stash file status: Will recoded some stuff, is re-testing,
should have something for review soon.

Incremental prop: Ken still working on it, hoping to merge something
to the trunk tonight.

Apple: lxs is still analyzing Apple patches, some need review from Ken
& Tom; need to talk to Apple about licensing. Authz plugin API should
be reviewed on krbdev.

MySQL: Robert is making progress getting plugin working. May have
found a way to extend the protocol without breaking backwards
compatibility.

Tom is trying to finish putting together a coding standards proposal,
and revised roadmap for development, perhaps projecting a few years
(and multiple releases) out.

IETF: Ken - referrals doc, main open areas (IIRC) are server
canonicalization and security. Tom - assigned numbers for Kerberos,
moving to IANA.

Release Meeting Minutes

2008-05-19T17:36:28Z

KenRaeburn: add 2008-05-19

Public minutes of Kerberos Consortium Release Meetings arranged in reverse chronological order:

==May 2008==

[[Release Meeting Minutes/2008-05-19 | May 19, 2008 (2008-05-19)]]

[[Release Meeting Minutes/2008-05-12 | May 12, 2008 (2008-05-12)]]

[[Release Meeting Minutes/2008-05-05 | May 5, 2008 (2008-05-05)]]

==April 2008==
[[Release Meeting Minutes/2008-04-28 | April 28, 2008 (2008-04-28)]]

[[Release Meeting Minutes/2008-04-14 | April 14, 2008 (2008-04-14)]]

==March 2008==
[[Release Meeting Minutes/2008-03-31 |March 31, 2008 (2008-03-31)]]

[[Release Meeting Minutes/2008-03-24 |March 24, 2008 (2008-03-24)]]

[[Release Meeting Minutes/2008-03-17 |March 17, 2008 (2008-03-17)]]

[[Release Meeting Minutes/2008-03-10 |March 10, 2008 (2008-03-10)]]

==February 2008==
[[Release Meeting Minutes/2008-02-04 |February 4, 2008 (2008-02-04)]]

==January 2008==
[[Release Meeting Minutes/2008-01-28 |January 28, 2008 (2008-01-28)]]

[[Release Meeting Minutes/2008-01-07 |January 7, 2008 (2008-01-07)]]

==December 2007==
[[Release Meeting Minutes/2007-12-17|December 17, 2007 (2007-12-17)]]

[[Release Meeting Minutes/2007-12-10|December 10, 2007 (2007-12-10)]]

Release Meeting Minutes/2008-05-19

2008-05-19T17:35:11Z

KenRaeburn: New page: '''Minutes of weekly release meeting for 2008-05-19:''' Tom will send email to krbdev about some changed release priorities, asking for feedback. Any progress on changing process for dis...

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

Tom will send email to krbdev about some changed release priorities, asking for feedback.

Any progress on changing process for discussing project proposals? We could use RT. We're trying to put together a proposal for updating our RT installation. Will describes a web app he's used. We could use RT with approval statements in comments. We may want to hold off until we've dealt with the web-comment-spam problem. Proposal: Use a special-purpose RT queue; sends to krbdev, receives mail from krbdev, so replies with ticket number get appended to the correct ticket. (No new ticket creation through this mechanism, so other traffic won't flood the RT database.)

Tom thinks we need more formal documentation of interface stability levels. We have some ideas internally, but we don't publish it. Maybe in header files? Distinguish API from ABI? Put it in our API documentation too? Sun's man pages have some of this sort of info. Some discussion of Sun processes.

Projects/domain realm referrals

2008-05-08T16:12:34Z

KenRaeburn: /* Desired Changes */ mention ietf draft

{{project-review|2008-05-12}}

== Desired Changes ==

Eliminate the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral (draft-ietf-krb-wg-kerberos-referrals) support in the KDC and providing the mapping information to clients through that protocol.

== Functional Requirements ==

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

== Design ==

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:
* the request is not a user-to-user authentication request
* the server principal name is unknown
* the referral flag is set in the request
* the requested server principal has two components
* the first component is not in a list configured in the KDC config file under "no_host_referral"
* the second component looks like a fully-qualified domain name
* ''(there may be additional conditions that should be imposed)''
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.

== Tasks/Milestones ==

* Library changes
* Library change test case
* KDC detection of the relevant cases
* KDC implementation of change of principal name

== Testing Plan ==

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Manual test of unknown name that maps to the local realm.

== Open Issues ==

Should the list of services to process this way be specified in the config file, or is a hardcoded set adequate at first? (Meta-issue: Should config information that is realm-specific but not KDC-specific be moved into the database from the config file?)

Should we use a list of services, or just process all two-element names where the second component looks like a domain name?

Do we want to add cross-realm test cases to the automated tests? I think currently only the DejaGnu-based tests are set up to manage running a KDC and additional client programs, and they're not set up to manage multiple realms.

==Review==

This section documents the review of the project according to [[Project policy]].
It is divided into multiple sections. First, approvals should be listed. To list an approval type
:<nowiki>#~~~~</nowiki>
on its own line.
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with
:<nowiki>--~~~~</nowiki>
and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.

===Approvals===

===Discussion===

Projects/domain realm referrals

2008-05-08T16:11:06Z

KenRaeburn: /* Design */ do by default, configure exceptions

{{project-review|2008-05-12}}

== Desired Changes ==

Eliminate the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral support in the KDC and providing the mapping information to clients through that protocol.

== Functional Requirements ==

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

== Design ==

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:
* the request is not a user-to-user authentication request
* the server principal name is unknown
* the referral flag is set in the request
* the requested server principal has two components
* the first component is not in a list configured in the KDC config file under "no_host_referral"
* the second component looks like a fully-qualified domain name
* ''(there may be additional conditions that should be imposed)''
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.

== Tasks/Milestones ==

* Library changes
* Library change test case
* KDC detection of the relevant cases
* KDC implementation of change of principal name

== Testing Plan ==

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Manual test of unknown name that maps to the local realm.

== Open Issues ==

Should the list of services to process this way be specified in the config file, or is a hardcoded set adequate at first? (Meta-issue: Should config information that is realm-specific but not KDC-specific be moved into the database from the config file?)

Should we use a list of services, or just process all two-element names where the second component looks like a domain name?

Do we want to add cross-realm test cases to the automated tests? I think currently only the DejaGnu-based tests are set up to manage running a KDC and additional client programs, and they're not set up to manage multiple realms.

==Review==

This section documents the review of the project according to [[Project policy]].
It is divided into multiple sections. First, approvals should be listed. To list an approval type
:<nowiki>#~~~~</nowiki>
on its own line.
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with
:<nowiki>--~~~~</nowiki>
and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.

===Approvals===

===Discussion===

Projects/domain realm referrals

2008-04-29T18:13:57Z

KenRaeburn: /* Design */ don't do it for u2u

{{project-review|2008-05-12}}

== Desired Changes ==

Eliminate the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral support in the KDC and providing the mapping information to clients through that protocol.

== Functional Requirements ==

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

== Design ==

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:
* the request is not a user-to-user authentication request
* the server principal name is unknown
* the referral flag is set in the request
* the requested server principal has two components
* either the first component is a recognized service name (this may be hardcoded initially) or the name type is host-based
* the second component looks like a fully-qualified domain name
* ''(there may be additional conditions that should be imposed)''
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.

== Tasks/Milestones ==

* Library changes
* Library change test case
* KDC detection of the relevant cases
* KDC implementation of change of principal name

== Testing Plan ==

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Manual test of unknown name that maps to the local realm.

== Open Issues ==

Should the list of services to process this way be specified in the config file, or is a hardcoded set adequate at first? (Meta-issue: Should config information that is realm-specific but not KDC-specific be moved into the database from the config file?)

Should we use a list of services, or just process all two-element names where the second component looks like a domain name?

Do we want to add cross-realm test cases to the automated tests? I think currently only the DejaGnu-based tests are set up to manage running a KDC and additional client programs, and they're not set up to manage multiple realms.

==Review==

This section documents the review of the project according to [[Project policy]].
It is divided into multiple sections. First, approvals should be listed. To list an approval type
:<nowiki>#~~~~</nowiki>
on its own line.
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with
:<nowiki>--~~~~</nowiki>
and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.

===Approvals===

===Discussion===

Projects/domain realm referrals

2008-04-28T20:50:27Z

KenRaeburn: /* Desired Changes */

{{project-review|2008-05-12}}

== Desired Changes ==

Eliminate the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral support in the KDC and providing the mapping information to clients through that protocol.

== Functional Requirements ==

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

== Design ==

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:
* the server principal name is unknown
* the referral flag is set in the request
* the requested server principal has two components
* either the first component is a recognized service name (this may be hardcoded initially) or the name type is host-based
* the second component looks like a fully-qualified domain name
* ''(there may be additional conditions that should be imposed)''
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.

== Tasks/Milestones ==

* Library changes
* Library change test case
* KDC detection of the relevant cases
* KDC implementation of change of principal name

== Testing Plan ==

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Manual test of unknown name that maps to the local realm.

== Open Issues ==

Should the list of services to process this way be specified in the config file, or is a hardcoded set adequate at first? (Meta-issue: Should config information that is realm-specific but not KDC-specific be moved into the database from the config file?)

Should we use a list of services, or just process all two-element names where the second component looks like a domain name?

Do we want to add cross-realm test cases to the automated tests? I think currently only the DejaGnu-based tests are set up to manage running a KDC and additional client programs, and they're not set up to manage multiple realms.

==Review==

This section documents the review of the project according to [[Project policy]].
It is divided into multiple sections. First, approvals should be listed. To list an approval type
:<nowiki>#~~~~</nowiki>
on its own line.
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with
:<nowiki>--~~~~</nowiki>
and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.

===Approvals===

===Discussion===

Projects/domain realm referrals

2008-04-28T20:46:54Z

KenRaeburn: move open testing issue into open-issues section; put up for review

{{project-review|2008-05-12}}

== Desired Changes ==

Eliminate the need for the domain_realm mapping table on the client side, in the common case.

== Functional Requirements ==

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

== Design ==

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:
* the server principal name is unknown
* the referral flag is set in the request
* the requested server principal has two components
* either the first component is a recognized service name (this may be hardcoded initially) or the name type is host-based
* the second component looks like a fully-qualified domain name
* ''(there may be additional conditions that should be imposed)''
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.

== Tasks/Milestones ==

* Library changes
* Library change test case
* KDC detection of the relevant cases
* KDC implementation of change of principal name

== Testing Plan ==

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Manual test of unknown name that maps to the local realm.

== Open Issues ==

Should the list of services to process this way be specified in the config file, or is a hardcoded set adequate at first? (Meta-issue: Should config information that is realm-specific but not KDC-specific be moved into the database from the config file?)

Should we use a list of services, or just process all two-element names where the second component looks like a domain name?

Do we want to add cross-realm test cases to the automated tests? I think currently only the DejaGnu-based tests are set up to manage running a KDC and additional client programs, and they're not set up to manage multiple realms.

==Review==

This section documents the review of the project according to [[Project policy]].
It is divided into multiple sections. First, approvals should be listed. To list an approval type
:<nowiki>#~~~~</nowiki>
on its own line.
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with
:<nowiki>--~~~~</nowiki>
and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.

===Approvals===

===Discussion===

Projects/domain realm referrals

2008-04-28T20:43:32Z

KenRaeburn: move open issues to bottom

{{project-early}}

== Desired Changes ==

Eliminate the need for the domain_realm mapping table on the client side, in the common case.

== Functional Requirements ==

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

== Design ==

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:
* the server principal name is unknown
* the referral flag is set in the request
* the requested server principal has two components
* either the first component is a recognized service name (this may be hardcoded initially) or the name type is host-based
* the second component looks like a fully-qualified domain name
* ''(there may be additional conditions that should be imposed)''
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.

== Tasks/Milestones ==

* Library changes
* Library change test case
* KDC detection of the relevant cases
* KDC implementation of change of principal name

== Testing Plan ==

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Manual test of unknown name that maps to the local realm.

Do we want to add cross-realm test cases to the automated tests? I think currently only the DejaGnu-based tests are set up to manage running a KDC and additional client programs, and they're not set up to manage multiple realms.

== Open Issues ==

Should the list of services to process this way be specified in the config file, or is a hardcoded set adequate at first? (Meta-issue: Should config information that is realm-specific but not KDC-specific be moved into the database from the config file?)

Should we use a list of services, or just process all two-element names where the second component looks like a domain name?

Extent of automated testing (see above).

Projects/domain realm referrals

2008-04-28T20:42:19Z

KenRaeburn:

{{project-early}}

== Desired Changes ==

Eliminate the need for the domain_realm mapping table on the client side, in the common case.

== Functional Requirements ==

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

== Design ==

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:
* the server principal name is unknown
* the referral flag is set in the request
* the requested server principal has two components
* either the first component is a recognized service name (this may be hardcoded initially) or the name type is host-based
* the second component looks like a fully-qualified domain name
* ''(there may be additional conditions that should be imposed)''
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.

== Open Issues ==

Should the list of services to process this way be specified in the config file, or is a hardcoded set adequate at first? (Meta-issue: Should config information that is realm-specific but not KDC-specific be moved into the database from the config file?)

Should we use a list of services, or just process all two-element names where the second component looks like a domain name?

== Tasks/Milestones ==

* Library changes implemented.
* Library change test case implemented.
* KDC detection of the relevant cases
* KDC implementation of change of principal name

== Testing Plan ==

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Manual test of unknown name that maps to the local realm.

Do we want to add cross-realm test cases to the automated tests? I think currently only the DejaGnu-based tests are set up to manage running a KDC and additional client programs, and they're not set up to manage multiple realms.

Projects/domain realm referrals

2008-04-28T20:37:42Z

KenRaeburn: New page: {{project-early}} == Desired Changes == Eliminate the need for the domain_realm mapping table on the client side, in the common case. == Functional Requirements == Clients should be ab...

{{project-early}}

== Desired Changes ==

Eliminate the need for the domain_realm mapping table on the client side, in the common case.

== Functional Requirements ==

Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).

The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.

== Design ==

Use a new function, with most of the body of the current krb5_get_host_realm:

krb5_error_code
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)

Add a field to the accessor structure, to export it.

In the KDC code, in TGS processing, if:
* the server principal name is unknown
* the referral flag is set in the request
* the requested server principal has two components
* either the first component is a recognized service name (this may be hardcoded initially) or the name type is host-based
* the second component looks like a fully-qualified domain name
* ''(there may be additional conditions that should be imposed)''
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.

== Open Issues ==

Should the list of services to process this way be specified in the config file, or is a hardcoded set adequate at first? (Meta-issue: Should config information that is realm-specific but not KDC-specific be moved into the database from the config file?)

Should we use a list of services, or just process all two-element names where the second component looks like a domain name?

== Tasks/Milestones ==

* Library changes implemented.
* Library change test case implemented.
* KDC portion implemented.

== Testing Plan ==

Unit test for the new library routine.

Manual test of cross-realm case with kvno.

Do we want to add cross-realm test cases to the automated tests? I think currently only the DejaGnu-based tests are set up to manage running a KDC and additional client programs, and they're not set up to manage multiple realms.

Talk:Coding style

2008-04-14T23:51:44Z

KenRaeburn: New page: I think the bits about not passing NULL to realloc or free are obsolete. So is allowing K&R style function declarations or definitions in new code instead of using prototype style. Using...

I think the bits about not passing NULL to realloc or free are obsolete. So is allowing K&R style function declarations or definitions in new code instead of using prototype style.

Using calloc or memset with pointer fields isn't so much wrong as incomplete. It's probably reasonable to clobber whatever might have been there before (unless we've got ''good'' tools for tracking uninitialized storage, and we think we meant to initialize everything), it just isn't guaranteed to give you null pointers, so if you want pointers initialized to null, you should do that also, explicitly.

--[[User:KenRaeburn|KenRaeburn]] 19:51, 14 April 2008 (EDT)

User:KenRaeburn

2008-04-10T01:22:09Z

KenRaeburn: New page: Ken Raeburn MIT Kerberos Consortium raeburn @ mit

Ken Raeburn

MIT Kerberos Consortium

raeburn @ mit

Release Meeting Minutes/2008-02-04

2008-02-04T23:02:41Z

KenRaeburn: minor correction to my comments

'''Minutes of weekly release meeting for 2008-02-04:'''

Will: Out sick last week.

Tom: Who is up to date in Daptiv?

Alexis: Up to date

Ken: Behind, needs to fix timescales

Kevin: Up to date

Ken: Working on a lot of stuff unrelated to 1.7

Tom: Should we add non-1.7 projects to make it easier to see who is doing what?

Ken, Steve: Yes

Tom: Trying to reproduce database corruption bug. Partial progress.

Will: Shawn Emery and Tom in communication about database corruption?

Tom: Yes

Will: Shawn had something that reproduces this?

Tom: We have one test case which reproduces some of the corruption we've seen. Describes test case with a record split on index 0.

Ken: Can we replace with a different database? SQLite plugin?

Will: Sun looking into SQLite already.

Ken: Believes SQLite license is sufficiently public domain for our purposes. Apple also using SQLite. Has heard concerns about SQLite being slower than Berkeley DB.

Will: Would there be any problem with a plugin in MIT Kerberos for SQLite?

Tom: Plugin isn't a problem for MIT. Vendors might have an issue if we bundle SQLite with MIT Kerberos. Would make sources considerably larger (1MB of sources).

Ken: Could choose to not build it on platforms where SQLite libraries already exist.

Will: Sun uses SQLite in some components. Also just bought MySQL. Thinks Nico uses SQLite. Sun is interested in a more reliable and robust database backend than LDAP or Berkeley DB.

Tom: Berkeley DB is well-tested and very mature. Unfortunately 4.4 BSD had the last incarnation of Berkeley DB under a license we could use so we are using an old version. MIT Kerberos will compile against more recent Berkeley DB versions.

Ken: Tested Berkeley DB versions 3 and 4.

Tom: No idea if anyone is using Kerberos with more recent versions of Berkeley DB. However given the interest in SQLite we should bring it up to the board and try to find resources.

Will: My manager may want me to switch to working on SQLite plugin instead of the enctype migration work.

Steve: How is our work going? Been working with Sun since October officially but seems like we aren't really getting to collaborate as much as we'd like.

Will: Feel like I haven't gotten a chance to really work on the Consortium work due to hardware issues, holidays, illness, LDAP bugs, release requirements, etc. Everything else was high priority.

Steve: That's understandable. Just want to flag that we've got a commitment from Sun for 6 months of 2 people at 25% time. Don't want to get into a state where we save all the work until the end and then don't have reasonable projects or deadlines. Even if this particular project isn't working we could use QA, testing infrastructure, new services (eg: OpenGrok), etc.

Will: Need to talk to manager about this.

Will: What is the project tracking system you are using?

Steve: Daptiv PPM. Is MIT's project tracking system. Have getting Sun folks accounts as an action item. Should be easy if you have an MIT account.

Will: Yes I have an MIT account. Do all board members get access to this?

Steve: Any board members can get access to this, but I suspect most don't want that fine grained detail. However since you're working so closely with us it should be useful to you.

Tom: Any other updates, issues, interesting developments?

Alexis: CCAPI v2 needed for Windows. Working on it. Will delay other tasks by approximately a week.

Kevin: Coverity Update. Have access to web site and downloaded their tool. Currently scanning krb5 sources and all other open source projects is done by one guy. Trying to move to a model where the open source projects run the tools themselves, upload dump files to an ftp site and he will run the proprietary tools on them and post results. Not currently automated, but working on that. Analysis takes approximately twice as long as a build.

Tom: What are the tool requirements? OS?

Kevin: Coverity wants to start with Linux first. Need to be able to protect access to the tool.

Ken: Can we talk about results of the tool output? Can we publish our results?

Steve: We should look at the license.

Tom: Do we have licenses?

Kevin: Haven't signed anything yet or received any formal notices. Will look for READMEs in tool tarball.

Steve: Would it be easier to use commercial project?

Kevin: Commercial product is expensive. Will investigate licensing of commercial product. Would get both pieces of the tool and not have to deal with Coverity.

Ken: Will help Kevin with linux build.

Steve: Has anyone looked at the user manual posted to comp.protocols.kerberos?

Ken: Printed it but not read it. About 40 pages. There are similar how-to guides out there but this may be one of the larger ones I've seen.

Release Meeting Minutes

2008-02-04T17:55:27Z

KenRaeburn: /* January 2008 */ add 28th

Public minutes of Kerberos Consortium Release Meetings arranged in reverse chronological order:

==January 2008==
[[Release Meeting Minutes/2008-01-28 |January 28, 2008 (2008-01-28)]]

[[Release Meeting Minutes/2008-01-07 |January 7, 2008 (2008-01-07)]]

==December 2007==
[[Release Meeting Minutes/2007-12-17|December 17, 2007 (2007-12-17)]]

[[Release Meeting Minutes/2007-12-10|December 10, 2007 (2007-12-10)]]