Project review: GSS credential store extensions

[Sam Hartman]

>>>>> "Nico" == Nico Williams <nico at cryptonector.com> writes:

    Nico> On Thu, Jul 12, 2012 at 11:59 AM, Sam Hartman <hartmans at mit.edu> wrote:
    >>>>>>> "Nico" == Nico Williams <nico at cryptonector.com> 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.

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

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
counting.
I'm fine with either answer, but would it spelled out.

--Sam