Project review: GSS credential store extensions

Sam Hartman hartmans at MIT.EDU
Thu Jul 12 13:16:34 EDT 2012

>>>>> "Nico" == Nico Williams <nico at> writes:

    Nico> On Thu, Jul 12, 2012 at 11:59 AM, Sam Hartman <hartmans at> wrote:
    >>>>>>> "Nico" == Nico Williams <nico at> writes:
    Nico> In Simo's proposal the mechglue/mechanism will never output a cred
    Nico> store, thus there's no memory management problem.
    >> Consider what happens when the mech glue or a stacked mechanism wants to
    >> augment the cred store configuration.
    >> I.E. consider a mech glue that allows an admin to configure parameters
    >> to pass into a mechanism.
    >> Or consider how Moonshot might interact with Kerberos.

    Nico> But I think then the caller is the glue or the stacked mechanism and
    Nico> it creates a new cred store struct and later frees the bits its
    Nico> responsible for.  That part of Greg's response is good enough, IMO.

Then I'm going to say there seems to be insufficient support for my

There's one other thing I'd like to have documented. If I'm copying a
cred store structure, MAY I assume the const pointers for value are null
terminated? Argument for yes: principle of least surprise. Argument for
no: allows people to have nulls in them if they have a mechanism for
I'm fine with either answer, but would it spelled out.


More information about the krbdev mailing list