* Sam Hartman: >>>>>> "Simo" == Simo Sorce <s...@redhat.com> writes: > > Simo> Wherever possible you should recommend people use GSSAPI and > Simo> not krb5 APIs directly, unless they are building tools > Simo> specifically to manage aspects of krb5 (acquiring tickets, > Simo> managing ccaches, etc.) > > I agree with the above. > I also think that the simple client referred to in the subject has a > bunch of anti-patterns. > As an example, I don't think it integrity protects or encrypts its > exchanges; I think it's too simple to actually be useful in today's > world. > > That said, it looks like krb5_auth_con_genaddrs is probably the API you > want to use instead of krb5_gen_portaddr. It takes an auth context and > a socet FD and extracts addresses from the socket FD. > > I suspect that the auth context machinery will generate the replay cache > name for you, and again, you don't need that API either. > But please use GSS-API instead:-)
I need to fix Authen::Krb5 (a Perl wrapper) not rely on this krb5 internals. Obviously, this is going to stay a krb5 wrapper, and won't switch to GSSAPI. So I'd really appreciate if someone would fix the appl/simple/client/sim_client.c example not to rely on <k5-int.h>, so that I can apply the parallel changes to the Perl port of this example code. The alternative would be to delete all this code from Authen::Krb5. (The wrappers for non-public krb5 functions have to go either way.) Thanks, Florian ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos