This bug has its roots in the UMICH replication code. The following patch was used against svr_principal.c to prevent the core dumps. This should probably be sent back to the UMICH folks for review (this is just a work- around without any investigation about correctness) now that the real culprit has been identified. Index: svr_principal.c =================================================================== RCS file: /disk3/CVS/Krb5/src/lib/kadm5/srv/svr_principal.c,v retrieving revision 1.2 diff -c -r1.2 svr_principal.c *** svr_principal.c 2002/05/31 00:12:16 1.2 --- svr_principal.c 2002/10/09 07:25:16 *************** *** 939,944 **** --- 939,946 ---- krb5_error_code ret; for (x = 0; x < n_new_key_data; x++) { + if (new_key_data[x].key_data_length[0] == 0) + continue; if (ret = krb5_dbekd_decrypt_key_data(context, &master_keyblock, &(new_key_data[x]), *************** *** 946,951 **** --- 948,955 ---- return(ret); for (y = 0; y < n_pw_hist_data; y++) { for (z = 0; z < pw_hist_data[y].n_key_data; z++) { + if (pw_hist_data[y].key_data[z].key_data_length[0] == 0) + continue; if (ret = krb5_dbekd_decrypt_key_data(context, hist_keyblock, *************** *** 1004,1009 **** --- 1008,1015 ---- memset(hist->key_data, 0, n_key_data*sizeof(krb5_key_data)); for (i = 0; i < n_key_data; i++) { + if (key_data[i].key_data_length[0] == 0) + continue; if (ret = krb5_dbekd_decrypt_key_data(context, &master_keyblock, &key_data[i],