Followup: Problems with krb5_get_in_tkt()

[Barry Jaspan]

As so often happens, I had a couple realizations after sending my previous 
message.

If a program calls krb5_get_in_tkt_with_skey() with a krb5_keyblock, the 
enctype is already known; it is in the krb5_keyblock structure.  There is 
no need for krb5_get_in_tkt() to iterate all enctypes until it finds the 
match.

This implies that the key and ktypes parameters to _with_skey() should be 
mutually exclusive.  If a program is passing in a key, the enctype is 
fixed, so the ktypes parameter will cause an error unless it matches the 
key, in which case it is redundant.  If a program is not passing in a key, 
then ktypes makes sense, because really it is just going to get passed to 
_with_keytab() to extract specific-enctype keys from the default 
keytab.  In this case, of course, the program might as well have called 
_with_keytab() directly, but it didn't.

Therefore, if this were the api design phase, I'd suggest that the ktypes 
parameter be removed from _with_skey(), since it is never necessary or 
useful.  I assume we can't really change this function's signature, 
though.  What we can do is make the function work correctly in a case where 
it presently does not.  So I think that if a program calls _with_skey() 
with key != NULL and ktypes == NULL, _with_skey() should cons up the 
appropriate zero-terminated ktypes array and pass it on to get_in_tkt().

Unless, of course, I'm wrong for some reason. ;-)

My other questions (about the switch from default_tkt_enctypes to a 
hard-coded array, krb5_obtain_padata(), permitted_enctypes, and 
skey_keyproc) are still unresolved, at least in my confused little head.

Barry