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

[Chris Hecker]

I have versions of both perl packages (krb5 and admin) that I work on
locally and have assumed I’d contribute back at some point.  It would be a
shame to delete them from cpan, they work well after some fixes.  I use my
versions in production.

I have said this before on the list and it’s not a very popular thing to
say, but I program to the krb5 public API, and it is a nice and clean and
performant and simple and portable and flexible API, and GSSAPI looks like
none of those things, it looks like a mess to use (just from looking at it
for my needs, I have never programmed with it).  So, I hope there isn’t
some movement to deprecate the lowlevel public krb5 API, because it is very
useful for me at least.

Chris


On Fri, Feb 24, 2023 at 08:55 Sam Hartman <hartmans at debian.org> wrote:

> >>>>> "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.
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>