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

[Nico Williams]

On Fri, Feb 24, 2023 at 01:50:58PM -0500, Ken Hornstein via Kerberos wrote:
> >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.

If you're just trying to set up a GSS context between a client and a
server, then GSS is really simple, and much simpler than the krb5 API.

If you have to deal with where credentials are (what ccaches, etc.) or
acquiring them, then historically you couldn't really do that with GSS,
bit now with the new gss_acquire_cred_from() and gss_store_cred_into()
functions you can.

> Dude, you are NOT the only one who feels that way, and I can't even
> BELIEVE people argue otherwise!  Yes, the GSSAPI is a mess; there is
> no getting around it.  The krb5 API is about 100x simpler (there are
> more functions, true, but most of the time you only need a handful
> of them).  I've used both; there's just no comparison.  I understand
> why the GSSAPI was created and the point of it and I use it when I
> feel it is appropriate; I understand why it is specified in protocol
> standards.  But in the service of making it "generic" it ended up being
> very complicated.  And if you want to have your protocol only require a
> single round trip, you're stuck either calling the krb5 API directly OR
> assuming that your GSSAPI mechanism will complete in a single round trip
> (the latter is what Microsoft chose for their GSSAPI HTTP protocol),
> which in my mind kind of negates the "g" in GSSAPI.

The krb5 API is a mess too.  And API compatibility between Heimdal and
MIT isn't complete.

With GSS though, with the new gss_acquire_cred_from() and
gss_store_cred_into(), I find there's very little need for krb5 APIs.

For example, in a PR to Heimdal I've a GSS-based equivalent of kinit
that has practically the same functionality as the Heimdal kinit
command.  The only thing it doesn't have is the ability to let the KDC
drive prompting, though I think I could do something about that too by
encoding the necessary information into minor status codes.

> However, one thing is worth mentioning: in my experience the GSSAPI
> is portable.  The details of the krb5 API are basically tied to the
> particular Kerberos implementation you're using, and that means you're
> stuck either with a lot of compatibility code OR you have to compile
> your preferred Kerberos implementation for your target platform, which
> presents it's own issues.  If I want a truly portable application then I
> do use the GSSAPI.

Basically.

Nico
--