appl/simple/client/sim_client.c uses internal APIs

[Sam Hartman]

>>>>> "Florian" == Florian Weimer <fweimer at redhat.com> writes:

    Florian> * Sam Hartman:
    >>>>>>> "Simo" == Simo Sorce <simo at 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.