Cleanups

This page describes opportunities for internal code cleanups. Anything to do with a user-facing or developer-facing behavior should go elsewhere (perhaps in an RT ticket, or somewhere related to the roadmap).

• sam2_process (preauth_sam2.c) should use a cleanup label instead of repeated free invocations. It is also long and should be broken up into smaller pieces if possible. (See Manual Testing for guidance on how to test at least part of this function.)

• kadmind's main() should not have repeated blocks of calls to release resources. It's probably unnecessary to release resources on error exit (plenty of other programs don't bother).

• k5-utf.8 uses its own conditionals for fixed-length types instead of the ones from krb5.h. On a related note, ucdata.h uses krb5_ui_4 instead of krb5_ucs4 but callers in ucstr.c use krb5_ucs4 pointers, generating warnings.

• The build system used to have multiple configure.in files making use of an aclocal.m4. Now that we only have one configure.in, we don't really need a separate aclocal.m4.

• Not all variables in the build system's Makefile fragments (like pre.in) are used. For instance, SHLIB_TAIL_COMP and KRB5_SHLIBDIR appear to be unused. Some variables like INSTALL_PREFIX are just name variants of other variables and are only used in one or two places under the variant name.

• Account lockout decision logic is duplicated in the DB2 and LDAP KDB modules.

• The serialization framework has several levels of unnecessary nesting. Also, it passes every serialization call through a table lookup of magic numbers, which is unnecessary since we always know what we're serializing (except for krb5_serialize_data, which is not used outside of test programs and is not a public API despite the name).

• lib/krb5/os appears to have a couple of different functions to generate ADDRTYPE_ADDRPORT addresses (one in mkfaddr.c and another in full_ipaddr.c).

• klist and kinit (at least) still have some internal vestiges from when they supported krb4 and krb5 credentials, and could be simplified.

• The kdcpreauth pluggable interface uses the new plugin support functions, but does not have a proper consumer interface as described in Projects/Plugin_support_improvements#Consumer_interface.

• kdc_preauth.c could be simplified by simply inserting informational padata values into the returned sequence, rather than having fake preauth systems for each informational preauth type.

• It's no longer our practice to use krb5_xfree() instead of free(), but it's still used in a few places (kdb5.c and the LDAP KDB module).

• It's no longer our practice to use krb5_x() to make calls through function pointers, but it's still used in a few places (ktfns.c and rcfns.c).

• Some kdc_util.c functions take krb5_db_entry structures instead of pointers.

• The LDAP KDB module maintains a connection pool, but only ever uses one connection (since our KDC is single-threaded).

• krb5_rc_default and krb5_rc_default_name are not part of our public API and are not used in the tree.

• Various parts of lib/gssapi still use K&R-style function definitions.

• lib/gssapi/mechglue should use the MIT krb5 style, not the Solaris coding style with tabs.

• lib/gssapi/generic contains some utility functions which are specific to the krb5 mech and should be located in lib/gssapi/krb5.

• Some parameters in osconf.hin are unused (like KDC_PORTNAME and KDC_SECONDARY_PORTNAME), or appear to be used but are never really used (like KRB5_DEFAULT_ADMIN_ACL and DEFAULT_ADMIN_ACL).

• kpropd's design can be simplified:
  • Currently, it forks to handle each incoming connection, but then waits for the child process. This could be done without forking, although doit() would have to be modified to avoid using exit() or an aborting SIGALRM handler.
  • Currently kpropd relies on dual-stack support to handle both IPv4 and IPv6 connections so that it can use a single blocking accept() call to wait for incoming connections. Some platforms such as OpenBSD don't have dual-stack support. We should open a listening socket for each address family and use libverto to wait for connections on both of them.
  • Currently, if iprop is enabled, a child process is used to handle incoming connections, but using libverto, the same process should be able to handle both. The process wouldn't ask for iprop updates while processing a kprop connection (since that handling is synchronous), but that should be okay.

• The libkdb5 interface includes krb5_db_setup_lib_handle(), which has no caller-visible semantics (it is invoked internally when needed). That function can be removed from the interface, since we don't guarantee interface stability for that library.

• krb5_db_get_age() and its associated DAL interface can be removed.

• The krb5_db_entry "len" field has no caller-useful semantics. krb5_db_put_principal will abort with the DB2 back end if the len field is not set to the magic value KRB5_KDB_V1_BASE_LENGTH. This field and the associated constant can be removed.

• The krb5_db_entry "n_tl_data" field is redundant with the length of the tl_data linked list, and isn't likely to have a significant performance impact since tl_data lists are short. It can be removed.

• The constants KRB5_TL_KADM5_E_DATA, KRB5_TL_RB1_CHALLENGE, KRB5_TL_USER_CERTIFICATE, KRB5_TL_LM_KEY, and KRB5_TL_X509_SUBJECT_ISSUER_NAME are unused and can likely be removed.

• The osa_policy_ent_rec "version" field has no caller-visible semantics; it is used internally by the DB2 module's xdr_osa_policy_ent_rec(), but a local variable would serve. The field can be removed.

• krb5_db_iter_policy takes a match_expr parameter and passes it through to the back end, but both back ends ignore it. The parameter can be removed.

• alt_prof.c contains functions for opening krb5.conf and kdc.conf, and for translating string, boolean, deltat, and integer values. These are largely redundant with normal profile handling functions. (One difference: alt_prof.c selects the last relation for a single-valued field, while regular profile functions select the first one. This is probably ignorable.)

• krb5_dbe_fetch_act_key_list is used only from kadmind, which immediately calls krb5_dbe_find_act_mkey and frees the list. This API could be replaced with an API to retrieve the active master key and its kvno, so that kadmind does not need to know about the existence of the master key activation list. The new API could also be used in kdb5_util's kdb5_update_princ_encryption in place of the three calls it uses to get the active master key.

• lib/gssapi contains duplicate ASN.1 DER code in mechglue/g_glue.c, generic/util_token.c, and spnego/spnego_mech.c. There are several opportunities for improvement here:
  • generic/util_token.c combines generic RFC 2743 ASN.1 framing with the two-byte RFC 1964 token header. If these were separated out, the framing code could be reused by SPNEGO and the mechglue, and the krb5 mech code would correspond more closely to the RFC 1964/RFC 4121 text.
  • Some of the lowest-level functions (DER tag and OID encoding) are redundant with lib/krb5/asn.1. They could be exported from libkrb5 as internal interfaces, or factored into libkrb5support, although the latter might be confusing.