Plug-in interfaces & internal APIs

[Ken Hornstein]

>On 05/16/2015 02:14 AM, Ken Hornstein wrote:
>> I know that doing your own PKINIT plugin requires a lot of internal
>> interfaces and changing that is hard.
>
>If you have another way of doing ASN.1 (such as asn1c), you could
>implement PKINIT without internal interfaces, in principle.

Yeah, but ... who really wants to do that?

>Of course, if you want to copy and modify the existing PKINIT module,
>our use of internal interfaces for ASN.1 (and possibly other things) is
>prohibitive.  The only really practical solution is to fork the whole
>tree, modify it, build it, and install only the PKINIT module.  We'd
>rather it not be necessary to modify PKINIT, and I think we've discussed
>what is required for that for your case and just haven't done the work.

Right, right ... I didn't want to come across like I was blaming you guys.
I got busy and didn't get a chance to work on giving you my changes.

However ... it does in my mind at least raise the larger issue is that it
would be nice for plugins to have the ability to access the ASN.1 encoding/
decoding routines for various Kerberos messages (I am thinking of SAM2
in particular).  I am not sure if there is some way to pass up the expanded
structure for the upper-level library to encode/decode (I know that the
way SAM2 works this is particular problematic).  Just thinking out loud
here; it's not an easy problem.

>You can call krb5_get_profile(), profile_get_*(), and profile_release().
> Those are all public libkrb5 APIs.  Avoid using the krb5_appdefault_*()
>interfaces; they are pretty broken.

Hm, I thought those were private, but I see now that they are in profile.h.
My apologies!

>> The second thing I've run into is storing per-principal information.
>> I know about the set_strings/get_strings interface; we use that, and
>> it's great!  But we have some cases where the plugin needs to modify
>> some data associated with the principal, and there is no set_strings
>> interface.  I know there's a callback to retrieve the principal record,
>> but I was wondering if that's the preferred method for storing stuff,
>> or if there should be an additional callback to store string data
>> (or TL_DATA) on a per-principal bases.
>
>For the moment, using the client_entry callback and libkdb5 is the only
>way to do this.

Fair enough; if that's the answer then I can live with that; I can understand
the issues with making set_strings public from the plugin API, but those
are consequences we've been living with and haven't really been a problem
for us.

Looking at other internal interfaces .... I see that I currently use
krb5int_c_combine_keys() and krb5int_c_mandatory_cksumtype().  The
former, okay, I know you're not crazy about exposing that one.  But
how about the latter?

--Ken