>>>>> "Florian" == Florian Weimer <fwei...@redhat.com> writes:
Florian> * 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:-) Florian> I need to fix Authen::Krb5 (a Perl wrapper) not rely on Florian> this krb5 internals. Obviously, this is going to stay a Florian> krb5 wrapper, and won't switch to GSSAPI. So I'd really Florian> appreciate if someone would fix the Florian> appl/simple/client/sim_client.c example not to rely on Florian> <k5-int.h>, so that I can apply the parallel changes to the Florian> Perl port of this example code. That code is not maintained, and I'd probably fix it with git rm. If you'll point me at upstreams sources for authen::krb5 I'll take a look and figure out a recommendation for whether delete or some sort of repair is best in that case. If the code actually provides integrity and confidentiality protection it is salvagable. Otherwise it is probably worth deleting. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos