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

[Chris Hecker]

I guess if I’m on a tear saying forbidden things, sometimes identity is all
you need, you don’t want all the samples to encrypt everything, because
that makes it look like you have to, which you don’t?  It is use-case
dependent, and krb5 is great because it is granular enough to let
developers choose what they do for their own use-cases.

In my opinion, the problem with the samples is they are in multiple places
if I recall, and they aren’t super obviously named so it’s not clear what
simple va sample means, etc.  But I used them all (including the u2u one)
in learning and they were useful, they could just use a little love and
organization and documentation.

If they’re calling internal stuff that should be fixed too obvs, but they
don’t need to be gutted.

Chris


On Fri, Feb 24, 2023 at 11:59 Chris Hecker <checker at d6.com> wrote:

>
> Yeah, by portable I meant I just compile the parts of krb5 client code I
> need when necessary.  The krb5 client is very portable and fairly small.  I
> strip out some stuff I don’t use,  but not too much.
>
> Chris
>
>
> On Fri, Feb 24, 2023 at 11:51 Ken Hornstein <kenh at cmf.nrl.navy.mil> 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.
>>
>> 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.
>>
>> 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.
>>
>> --Ken
>>
>