[39174] in Kerberos
Re: appl/simple/client/sim_client.c uses internal APIs
daemon@ATHENA.MIT.EDU (Sam Hartman)
Fri Feb 24 10:55:25 2023
From: Sam Hartman <hartmans@debian.org>
To: Florian Weimer <fweimer@redhat.com>
Cc: Simo Sorce <simo@redhat.com>, kerberos@mit.edu
In-Reply-To: <87edqfmi12.fsf@oldenburg.str.redhat.com>
Date: Fri, 24 Feb 2023 15:50:52 +0000
Message-ID: <01000186841ebd8f-d17ddc20-784d-4c20-93c9-ecab338de191-000000@email.amazonses.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
>>>>> "Florian" == Florian Weimer <fweimer@redhat.com> writes:
Florian> * Sam Hartman:
>>>>>>> "Simo" == Simo Sorce <simo@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
