appl/simple/client/sim_client.c uses internal APIs
Sam Hartman
hartmans at debian.org
Fri Feb 24 10:50:52 EST 2023
>>>>> "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.
More information about the Kerberos
mailing list