Project review: GSS credential store extensions

[Sam Hartman]

>>>>> "Simo" == Simo Sorce <simo at redhat.com> writes:

    Simo> On Thu, 2012-07-12 at 12:43 -0400, Sam Hartman wrote:
    >> >>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:
    >> 
    >> Ok. Well, add me to Nico in the strong disagreement camp here.  If it
    >> were just the buffers, I would agree with you.  
    >> I'm actually a bit puzzled about why you're bringing up buffers though;
    >> this structure does not include buffers.
    >> 
    >> My concern is the array
    >> of pointers to buffers and what happens when you want to try and
    >> manipulate them. My experience with memory management for oid sets
    >> suggests this is an area where even in non-performance-sensitive areas
    >> it gets really messy.
    >> 
    >> Even if Nico and I aren't able to build a consensus in favor of a better
    >> memory management approach, I think it's critical that we document the
    >> assumptions of this approach.  Namely, you cannot free a cred_set you
    >> didn't allocate. You cannot manipulate one; you must copy to manipulate.

    Simo> In my view the cred_store is not something you manipulate within gssapi,
    Simo> it's a configuration store for credential, not a 'communication means'.

    Simo> So leaving memory management to the application seem quite reasonable
    Simo> and safe.


I'm not OK with this, because I think it's entirely reasonable and
desirable for a mech glue or stacked mechanism to  configure a mechanism
it calls.

Given where people stand on these issues, I'm entirely fine saying that
the mechglue or stacked mechanism needs to copy the cred store
information to manipulate it. I'm also fine saying that the const char *
strings are null terminated.
I just think we need to write that down.