appl/simple/client/sim_client.c uses internal APIs
Nico Williams
nico at cryptonector.com
Fri Feb 24 15:56:17 EST 2023
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
--
More information about the Kerberos
mailing list