Project review: GSS credential store extensions
simo at redhat.com
Thu Jul 12 15:27:38 EDT 2012
On Thu, 2012-07-12 at 13:16 -0400, Sam Hartman wrote:
> >>>>> "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.
I used const char * because I want toi prevent use of arbitary binary
values, so from my end you get assurance they are numm terminated text
I am prepared even to go further and say they SHOULD be utf8 strings,
and not just random garbage except that I do not want to put any
requirement for validation at the moment because that seem frankly
Simo Sorce * Red Hat, Inc * New York
More information about the krbdev