[39171] in Kerberos
Re: appl/simple/client/sim_client.c uses internal APIs
daemon@ATHENA.MIT.EDU (Sam Hartman)
Thu Feb 23 12:39:41 2023
From: Sam Hartman <hartmans@debian.org>
To: Simo Sorce <simo@redhat.com>, Florian Weimer <fweimer@redhat.com>,
kerberos@mit.edu
In-Reply-To: <465b96c64cc9040b0498d511c7574080ff92c8a1.camel@redhat.com>
Date: Thu, 23 Feb 2023 17:34:52 +0000
Message-ID: <010001867f579798-1ec0eb99-5063-4a2c-8e72-e25400d41000-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
>>>>> "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:-)
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
