Difference between revisions of "Projects/Remove krb4"

Revision as of 17:22, 9 December 2008

The goal of this project is to remove most of the krb4 code from the Kerberos source code base.

What will be removed

For the most part, code will be removed if it is not compiled in without the --with-krb4 flag. Specific code to be removed includes:

• The libkrb4 and libdes425 libraries
• The krb524 daemon and client code (krb5_524_convert_creds will remain as a stub for ABI stability)
• Client program code to retrieve and manipulate krb4 tickets
• Application (rlogin, telnet, v4rcp, etc.) code to perform krb4 authentication
• The kerberosIV headers
• Test cases for krb4 functionality
• Build system conditionalization for compiling krb4 code
• krb4 request handling in the KDC
• fakeka support in the KDC
• loadv4/dumpv4 support in kdb5_util

What will be kept

Some krb4-related code should be kept because it is important in post-krb4 environments or would be disruptive to remove. These pieces of code include:

• Code to support KRB5_KDB_SALTTYPE_V4
• krb5_524_conv_principal and krb5_425_conv_principal
• The SRVTAB keytab type
• The setv4key RPC handler in kadmind
• The rst/wst (read srvtab/write srvtab) functions in ktutil

Except for rst/wst, all of these pieces are currently compiled in even without --with-krb4, and are implemented without referencing libkrb4 or the kerberosIV headers.

The rst/wst code in ktutil is currently implemented separately from the SRVTAB keytab code, and is not compiled in without --with-krb4. These functions will be reimplemented to be aliases for "rkt/wkt SRVTAB:pathname".

Timeline

Code removal is expected to take about two weeks and should be completed by December 19. This project is a deliverable for the krb5 1.7 release.

Pending Discussion

The CCache, KIM, and Windows code contain krb4-related code. This code is not compiled as part of the Unix release or covered by the Unix test suite. We will need to discuss resource allocation for removing krb4 code from these areas.

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

#~~~~

on its own line. The next section is for discussion. Use standard talk page conventions. In particular, sign comments with

--~~~~

and indent replies.

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

Approvals

1. SamHartman 17:22, 9 December 2008 (EST)

Discussion