krb4 get_svc_in_tkt() crashes and oddities

[Todd Zino]

While porting our authentication code from Unix to Windows (switching to 
the KFW 2.x stuff for linking, compiling, and headers), I have had several 
problems with the K4 krb_get_svc_in_tkt() function.

This had been used successfully under Unix to retrive a "krbtgt" from the 
kdc using the path to the srvtab as one of the arguments. This, of course, 
merely rearranges the variables for a krb_get_in_tkt() call with a 
srvtab_to_key() translator as the (*key_proc()) argument.

In Win32, this code is crashing, specifically when it gets down to this 
portion of krb_get_in_tkt():

         if (in_tkt_decrypt_again >= 0){
             (*key_proc)((char *)0,(char *)0,(char *)0,arg,(C_Block *)0);
         }

Which will call srvtab_to_key() with a bunch of nulls. srvtab_to_key() is 
basically a conduit for read_service_key() which has the line

         wcard = (instance[0] == '*') && (instance[1] == '\0');

which is where the crash is (since parameter char * instance is being 
called as (char *)0 as per the excerpt above from krb_get_in_tkt().

Is this a bug or a de facto implementation problem, i.e. I should use 
another function besides krb_get_svc_in_tkt() to do this procedure or there 
is an issue with which "version" of this to use, the one in the krb4 src 
tree or the one in the krb5 src tree (which includes its own krb4 sources) 
that both get distro'd with KFW 2.x? When I step debugged to find all this 
stuff, it was going into the krb4 one.

I'm also unsure of the role of this in_tkt_decrypt_again sentinal; is this 
only valid in prompt-for-password situations, or does it have a role in 
srvtab/keytab TGT auths as well? It had a value of 0 each time I stepped 
through this.

One more question on this topic: Why is krb_get_svc_in_tkt() not defined in 
krb.h, at least the "krb4" one? It is defined in the "kerberosIV/krb.h" of 
krb5. This has resulted in some link/compile problems when trying to make a 
dummy console .EXE that does nothing but call this with hardcoded values in 
its main() so I can see how persistant the problem is.

-Todd