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

On Fri, Feb 24, 2023 at 03:23:01PM -0800, Russ Allbery wrote:
> I use GSSAPI for new code because it is a *better* API (or, more
> precisely, a better *protocol*) that fixes various underlying issues and
> has better defaults.  But it is not *simpler*; quite the opposite, it's
> more tedious and annoying and weird, harder to debug because of the
> imposition of the generic layer that has a tendency to get in the way of
> understanding what's going on, and requires you think about both Kerberos
> and GSS concepts at the same time when implementing a non-trivial
> application instead of focusing only on Kerberos.

I'll grant that it's a better API and maybe not simpler.

Another complaint might be that GSS terminology is not the same as
Kerberos terminology, which then serves to confuse developers.

> Just to take another example, GSSAPI introduces yet another identity
> format and now you have to be aware of both the Kerberos identity and the
> GSS identity, which are sort of the same but not always.

Yes, this is true and annoying.  It's one way to support different
mechanisms with different naming.  Another is to require the application
know the details of each supported mechanism's naming -- that seems
hardly better.  This is mostly all a consequence of having disparate
security mechanisms to begin with.

Which is why, for a new mechanism, I would much prefer that it support
Kerberos naming.  Certainly I don't ever want to see a mechanism use
x.500 style naming again.

Nico
-- 
________________________________________________
Kerberos mailing list           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos