Re: appl/simple/client/sim_client.c uses internal APIs
Thank you for your help regarding this matter. In the end, I could not fix the Authen::Krb5 Perl module because there are some fundamental reference counting problems in it. The code sort-of works today because it papers over these issues by using internal libkrb5 APIs, which I suspect happen to work mostly by accident (that, or the code is actually dead because the reference counts never go to zero for some reason). This is a Perl XS issue, unrelated to Kerberos. It's fairly clear how to fix it in princple, but I haven't done any serious Perl programming in over a decade, and the upstream maintainer has archived the Git repository recently anyway. Thanks, Florian Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: appl/simple/client/sim_client.c uses internal APIs
* Sam Hartman: >>>>>> "Florian" == Florian Weimer writes: > > Florian> * Sam Hartman: > >>>>>>> "Simo" == Simo Sorce 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> , 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. The Perl translation is here: <https://metacpan.org/release/IOANR/Authen-Krb5-1.905/source/eg/simple_client> It's not an exact tranlation of the C because it creates a replay cache: # create the replay cache ($l,$r) = $ac->getaddrs(); $lap = Authen::Krb5::gen_portaddr($l,$s->sockport()); $rcn = Authen::Krb5::gen_replay_name($lap,"foobar"); $rc = Authen::Krb5::get_server_rcache($rcn); $ac->setrcache($rc); The setrcache part is missing in the C version, it seems. If the Perl example is still broken, we should of course remove it. Thanks, Florian Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: appl/simple/client/sim_client.c uses internal APIs
* Sam Hartman: >> "Simo" == Simo Sorce 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 , 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
appl/simple/client/sim_client.c uses internal APIs
The example program uses internal APIs not present in the public header file (krb5_gen_portaddr, krb5_gen_replay_name; the THIS IS UGLY part). Are there alternatives part of the public API? The issue here is that the example code has leaked outside of krb5 to other projects, and it only builds there because current compilers still support implicit function declarations. I would like to give guidance to the external users, but unfortunately I don't know anything about Kerberos. Thanks, Florian Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
