Maybe I miss something but I am not in control of the initialisation of the keyblock. The problem is mcreds->keyblock ->contents in krb5_copy_keyblock_data, which is not allocated in any function before and not provided by the user.
static krb5_error_code krb5_get_credentials(krb5_context context, krb5_flags options, krb5_ccache ccache, krb5_creds *in_creds, krb5_creds **out_creds) { krb5_error_code retval; krb5_creds mcreds; krb5_creds *ncreds; krb5_creds **tgts; krb5_flags fields; int not_ktype; retval = krb5_get_credentials_core(context, options, in_creds, &mcreds, &fields); . . . static krb5_error_code krb5_get_credentials_core(krb5_context context, krb5_flags options, krb5_creds *in_creds, krb5_creds *mcreds, krb5_flags *fields) { krb5_error_code ret = 0; . . . ret = krb5_copy_keyblock_data(context, &in_creds->keyblock, &mcreds->keyblock); Markus ----- Original Message ----- From: "Nicolas Williams" <[EMAIL PROTECTED]> To: "Markus Moeller" <[EMAIL PROTECTED]> Cc: "Ken Raeburn" <[EMAIL PROTECTED]>; <kerberos@mit.edu> Sent: Tuesday, October 16, 2007 12:05 AM Subject: Re: Bug in krb5_keyblock_data function on Solaris 10/Opensolaris > On Mon, Oct 15, 2007 at 11:44:30PM +0100, Markus Moeller wrote: >> You are right and some calling functions like krb5_copy_keyblock do >> allocate, but not krb5_get_credentials(_core) if I now read the code >> right. > > Whether it's a bug at all depends on what the krb5_get_credentials() API > docs say about increds->keyblock. The lack of MIT krb5 API docs doesn't > help. > > Now that you know what the calling convention for > krb5_copy_keyblock_data() you should be able to fix your test program to > properly initialize the keyblock field of the creds passed to > krb5_get_credentials() as input creds. > > [I'll try to refrain from getting into the problems with encoding > krb5_keyblock internals knowledge into your apps.] > > Nico > -- > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos