Project review: GSS credential store extensions
hartmans at MIT.EDU
Thu Jul 12 13:16:34 EDT 2012
>>>>> "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.
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