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

On Fri, Feb 24, 2023 at 01:22:16PM -0700, Chris Hecker wrote:
> It has been a long time since I made this evaluation so I don’t remember
> the details, but I definitely do all sorts of stuff with ccaches and
> keytabs and profiles and threads and static linking and controlling memory
> allocations and controlling sockets and file usage and whatnot, it seemed
> like GSSAPI would have been a nightmare.  Also, the design of krb5 is
> pretty clear, it is lowlevel, but everything is right there, it doesn’t try
> to hide much, which I value.

In GSS w/o the extensions I mentioned, you could not even do it, never
mind it being a nightmare.  But with those two extensions it's pretty
trivial to use whatever ccache or keytab you like.  Threading is not an
issue.  GSS doesn't do any BIO-like thing like OpenSSL, so it's
orthogonal to your sockets.  The IOV variants of per-message token
functions give you control over buffer allocations.

> Anyway, if others prefer GSSAPI that’s fine with me, I just wanted speak up
> and say there are some of us who like calling krb5 and kadm.

:)

Oh, the kadm5 API is a different nightmare.  It has a very MIT-centric
view of what a principal is.  Dealing with that in Heimdal is a serious
pain.  I'd much rather have something with a much easier to extend
representation of principals.  In Heimdal we have HDB-entry as an ASN.1
type, and it's much better than the kadm5_ent_rec in kadm5, though it's
still not great because it reflects the evolution of the HDB-entry
rather than what a standard representation should be.  Building mappings
between different schemas is a pain.

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