Project review: GSS credential store extensions

[Simo Sorce]

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.
> 
> 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.

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
strings.

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
excessive.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York